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.
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.