This is an archive of the discontinued LLVM Phabricator instance.

Add support for .ARM.exidx unwind information
ClosedPublic

Authored by tberghammer on Sep 29 2015, 7:23 AM.

Details

Summary

.ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception.

Diff Detail

Event Timeline

tberghammer retitled this revision from to Add support for .ARM.exidx unwind information.
tberghammer updated this object.
tberghammer added a reviewer: jasonmolenda.
tberghammer added a subscriber: lldb-commits.
labath added a subscriber: labath.Sep 29 2015, 7:53 AM

I don't know much about the arm unwind info, but I have some style comments from a casual read-through.

include/lldb/Symbol/UnwindTable.h
71

unique pointers should have names ending in _up

source/Symbol/ArmUnwindInfo.cpp
62

Is there a reason DataExtractor::GetULEB128 could not be reused?

jasonmolenda edited edge metadata.Sep 29 2015, 3:45 PM

Looks good to me, I don't have anything beyond Pavel's suggestions. I don't know the format of the ARM .exidx .extab unwind info so I don't have any feedback on the parsing of that.

I forgot about that code in RegisterContextLLDB::GetFullUnwindPlanForFrame() for cases where we have no FuncUnwinders object. The comment on that,

// No FuncUnwinders available for this pc (i.e. a stripped function symbol and -fomit-frame-pointer).
// Try using the eh_frame or the .ARM.exidx information relative to the current PC,
// and finally fall back on the architectural default unwind.

could be a little clearer. I'd describe it more like

No FuncUnwinders available for this pc (stripped function symbols, lldb could not augment
its function table with another source, like LC_FUNCTION_STARTS or eh_frame in ObjectFileMachO).
See if eh_frame or the .ARM.exidx tables have unwind information for this address, else
fall back to the architectural default unwind.

ObjectFileMachO.cpp reads the symbols for the object file and then augments those with the
LC_FUNCTION_STARTS (a raw list of start addresses for the the functions in the binary) or the
eh_frame function ranges. Having accurate function start addresses is critical for the instruction
profile unwinding.

Compact unwind format is not suitable for a source of function start addresses -- if two functions
have the same unwind signature and exist next to each other in the binary, compact unwind may
represent them as a single entry, etc. The ARM unwind formats may have the same behavior.

Anyway, that's something the ObjectFile reader for your platform would need to do and not
the topic of this patch.

BTW "Implemnted based on" -> "Implemented based on". And thanks for including the
reference name / revision / URL - that kind of pointer is a huge help for long-term maintenance.

jasonmolenda accepted this revision.Sep 29 2015, 3:46 PM
jasonmolenda edited edge metadata.

LGTM.

This revision is now accepted and ready to land.Sep 29 2015, 3:46 PM
tberghammer marked an inline comment as done.Sep 30 2015, 6:45 AM
tberghammer added inline comments.
source/Symbol/ArmUnwindInfo.cpp
62

DataExtractor is reading from a stream of bytes while the arm unwind info is encoded in a bit more complicated (and strange way). It is encoded as a list of 4 byte words and then the 1 byte values have to be read from it from the MSB byte to the LSB byte what isn't match with the order used by the DataExtractor.

This revision was automatically updated to reflect the committed changes.