This is an archive of the discontinued LLVM Phabricator instance.

FuncUnwinders: Add a new "SymbolFile" unwind plan
ClosedPublic

Authored by labath on May 9 2019, 7:19 AM.

Details

Summary

some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).

This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.

The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.

Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.

Diff Detail

Repository
rLLDB LLDB

Event Timeline

labath created this revision.May 9 2019, 7:19 AM

Looks good except the inline comment about all the unwind plans we have now. Would love to simplify this so that EH frame, compact unwind, ARM unwind, breakpad unwind all come from the symbol file or object files. Also be nice to have a register resolver that works without having a process so we can dump unwind info without needing a process.

include/lldb/Symbol/FuncUnwinders.h
123–125

Seems like the compact unwind should move into the ObjectFileMachO and ARM unwind should move into ObjectFileELF as part of this? We have so many unwind plans here, the logic is already too complex around the selection process. Seems like m_unwind_plan_compact_unwind, m_unwind_plan_arm_unwind_sp, and possibly even m_unwind_plan_eh_frame_augmented_sp and m_unwind_plan_debug_frame_augmented_sp should all be moved into the ObjectFile classes so they can be accessed by the symbol file. This will allow say ObjectFileMachO to determine which is the best to use for a given address, and also ObjectFileELF.

labath added a comment.May 9 2019, 9:35 AM

Looks good except the inline comment about all the unwind plans we have now. Would love to simplify this so that EH frame, compact unwind, ARM unwind, breakpad unwind all come from the symbol file or object files. Also be nice to have a register resolver that works without having a process so we can dump unwind info without needing a process.

I was also considering that (making unwind plan providers more pluggable), but I gave up after a day or two of experimenting. As I recall, the main problem was that there are places in code that go straight for a specific unwind plan instead of just asking for a "(non)call site unwind plan". Some of those use cases are relatively reasonable: e.g. one can ask for an eh_frame unwind plan even if he does know the exact symbol and it's boundaries where he's stopped at, but that is definitely not the case for the "instruction emulation" plan.

It wasn't clear to me how to reconcile these requirements, so I just went with the approach that preserves status quo. Given that most of these unwind plans are not tied to a specific object/symbol file format (I didn't realize that compact unwind is specific to mach-o), encapsulating them inside a plugin did not seem to be that important.

The thing that could help with the readability here is to avoid having a separate shared_ptr for the plan, and a bool flag for whether we attempted to create the plan. Encapsulating that into a single entity would go a long way towards making this class more readable, but it would also increase the size of this class (i'm not sure how much we care about that). There are also ways to do that without increasing the size (or even with decreasing it), but they would all be more or less magical, which I wasn't sure whether is worth it.

I definitely plan to look into making unwind plan computation possible without a running process but that will require us to get a different source of truth for the register eh/dwarf numbers (right now we get those from the remote stub), which is not going to be an easy task.

jasonmolenda accepted this revision.May 9 2019, 5:48 PM

Looks good to me.

Yes, we need to change from a model of "the remote stub teaches lldb everything about registers" to "lldb knows all the architectural / ABI register number details, asks the remote stub what numbers it uses for them when connected". The need to go through RegisterContext::ConvertBetweenRegisterKinds / RegisterContext::GetRegisterInfoAtIndex to get any information about registers is unfortunate.

I'm not super concerned about the size of the UnwindPlan or FuncUnwinders objects - we create them lazily as we unwind through functions in the process, so my guess is that even a long-running debug session will have on the order of thousands of these objects. The ABIs don't even bother to issue a single ArchDefault unwind plan and FunctionEntry unwind plan, handing out a new one for each FuncUnwinders object (ok that part is a little embarrassing, but again this isn't super high on the priority list to fix imo.)

This revision is now accepted and ready to land.May 9 2019, 5:48 PM

I'm not super concerned about the size of the UnwindPlan or FuncUnwinders objects - we create them lazily as we unwind through functions in the process, so my guess is that even a long-running debug session will have on the order of thousands of these objects. The ABIs don't even bother to issue a single ArchDefault unwind plan and FunctionEntry unwind plan, handing out a new one for each FuncUnwinders object (ok that part is a little embarrassing, but again this isn't super high on the priority list to fix imo.)

Ok, sounds good. I'll whip up a patch to merge the _sp and _tried fields into one entity.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMay 10 2019, 12:52 AM
Herald added a subscriber: abidh. · View Herald Transcript