This is the same as we do on arm64 already for the MSVC style label
symbols, but also handle the way GCC produces it - with all relocations
pointing at the .text section symbol, with various offsets.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/tools/llvm-readobj/COFF/x86_64-unwind-preferred-symbol-gcc.yaml | ||
---|---|---|
9 | Note that we might resolve the end address into the symbol of the next function that starts directly after, in some cases (if there's no padding inbetween), but that's hopefully tolerable. |
Improve the logic for picking the symbol for the end of the range, to avoid picking the start of the next function.
llvm/tools/llvm-readobj/Win64EHDumper.cpp | ||
---|---|---|
138 | Is repeatedly iterating over every symbol in the file going to cause performance issues? |
llvm/tools/llvm-readobj/Win64EHDumper.cpp | ||
---|---|---|
138 | Yes if this would be performance sensitive, we probably should populate some different data structure for it - but I think it's not. The original code that looks up the relocation, by scanning linearly over all relocations in the object file until it hits one at the right section+offset, also does a similar order of magnitude of iterations. |
llvm/tools/llvm-readobj/Win64EHDumper.cpp | ||
---|---|---|
138 | I suspect we wouldn't notice even if there were performance issues: probably very few people use llvm-readobj on files of non-trivial size. I guess if you're not making the existing issues substantially worse, it's fine. |
Note that we might resolve the end address into the symbol of the next function that starts directly after, in some cases (if there's no padding inbetween), but that's hopefully tolerable.