This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj] [COFF] Try to resolve symbols in unwind info on x86
ClosedPublic

Authored by mstorsjo on Sep 11 2021, 12:23 PM.

Details

Summary

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.

Diff Detail

Event Timeline

mstorsjo created this revision.Sep 11 2021, 12:23 PM
mstorsjo requested review of this revision.Sep 11 2021, 12:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 11 2021, 12:23 PM
Herald added a subscriber: MaskRay. · View Herald Transcript
mstorsjo added inline comments.Sep 11 2021, 12:30 PM
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.

mstorsjo updated this revision to Diff 372221.Sep 13 2021, 5:09 AM

Shrunk the text section of the test cases a little bit.

mstorsjo updated this revision to Diff 372314.Sep 13 2021, 12:17 PM

Improve the logic for picking the symbol for the end of the range, to avoid picking the start of the next function.

efriedma added inline comments.
llvm/tools/llvm-readobj/Win64EHDumper.cpp
138

Is repeatedly iterating over every symbol in the file going to cause performance issues?

mstorsjo added inline comments.Sep 13 2021, 12:58 PM
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.

efriedma added inline comments.Sep 13 2021, 1:17 PM
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.

rnk accepted this revision.Sep 13 2021, 3:20 PM

lgtm

This revision is now accepted and ready to land.Sep 13 2021, 3:20 PM