This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj][MachO] Support option --unwind for __eh_frame
Needs ReviewPublic

Authored by gkm on Jun 30 2021, 8:00 PM.

Details

Reviewers
jhenderson
clayborg
smeenai
int3
Group Reviewers
Restricted Project
Summary

LLD will soon prune redundant __eh_frame entries. In order to debug this in LLD, we need the capacity to dump and cross-check the __eh_frame section and __unwind_info sections.

This diff adds the __eh_frame dumper.

The dumper code is adapted from llvm/tools/llvm-readobj/DwarfCFIEHPrinter.h:PrinterContext<ELFT>::printEHFrame().

Diff Detail

Event Timeline

gkm created this revision.Jun 30 2021, 8:00 PM
gkm requested review of this revision.Jun 30 2021, 8:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 30 2021, 8:00 PM

You should try and find some Mach-O developers to assist with this, as I'm afraid I've got no real experience with it (my herald rule is dumb and just matches any llvm-readobj change). I know @smeenai and @alexander-shaposhnikov have been involved with the Mach-O side of llvm-objcopy, so are probably in a good place to review this too.

llvm/test/tools/llvm-readobj/MachO/eh_frame.yaml
1

Nit: add trailing "."

thakis added a subscriber: thakis.Jul 1 2021, 5:57 AM

That looks ok, but doesn't llvm-dwarfdump --eh-frame file do this already?

gkm added a comment.Jul 1 2021, 12:31 PM

That looks ok, but doesn't llvm-dwarfdump --eh-frame file do this already?

Ah yes, though the function addresses printed as pc=... are wrong. I will file a bug.

The ultimate goal with llvm-readobj is to dump any & all of __eh_frame, __compact_unwind, and __unwind_info, whereas the latter two are beyond the scope of llvm-dwarfdump.

gkm edited the summary of this revision. (Show Details)Jul 1 2021, 12:32 PM
gkm edited the summary of this revision. (Show Details)

That looks ok, but doesn't llvm-dwarfdump --eh-frame file do this already?

Ah yes, though the function addresses printed as pc=... are wrong. I will file a bug.

I think they're correct (?) They used to be wrong, but they seem to be fine now, at least in the examples I looked at – see unwinfo.py output here https://bugs.llvm.org/show_bug.cgi?id=50956 and comments about llvm-dwarfdump here https://github.com/nico/hack/blob/master/unwinfo.py#L63

The ultimate goal with llvm-readobj is to dump any & all of __eh_frame, __compact_unwind, and __unwind_info, whereas the latter two are beyond the scope of llvm-dwarfdump.

Yes, I think that's a good goal. There isn't a great way to do get a combined view at the moment.

If we need to cross check between the two outputs (eh_frame and unwind_info), do we want some sort of intermediate output so we can see the unwind info organized by address instead of random order?

llvm/tools/llvm-readobj/MachODumper.cpp
726–734

I am assuming we must print this all in this code so we can use the "W" dumper (as opposed to telling the CIE to dump itself to a raw_ostream)?

743–746

I really don't like how the FDE calls is start address "initial location" and the address range size "address range". Granted this is how it is documented in the DWARF spec, but I am not a huge fan of these names. If you need it the output to be true to the specficiation, then this is ok. But in general, I would much rather see a printed address range in the output something like:

range: [0x1000-0x2000)

instead of

initial_location: 0x1000
address_range: 0x1000 (end: 0x2000)

Also make sure that the start address range has been relocated. In the actual data it is PC relative, just make sure the address range makes sense and matches what llvm-dwarfdump outputs in its output:

00000018 0000001c 0000001c FDE cie=00000000 pc=00004d50...00004d6a
748

FYI: you can easily dump the unwind info for each FDE to show the unwind info in the row. The output looks like:

00000018 0000001c 0000001c FDE cie=00000000 pc=00004d50...00004d6a
  Format:       DWARF32
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:

  0x4d50: CFA=RSP+8: RIP=[CFA-8]

The last line dumps all of the rows that the FDE defines. Might be handy to include this information.

thakis added inline comments.Jul 1 2021, 3:42 PM
llvm/tools/llvm-readobj/MachODumper.cpp
689

That's a good point, the current factoring here makes it hard to do interleaved output by address like the output on https://bugs.llvm.org/show_bug.cgi?id=50956 . I think that's a useful way to present this information.

smeenai resigned from this revision.Apr 28 2022, 1:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 1:57 PM
int3 resigned from this revision.Jan 24 2023, 5:05 PM