On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote:
Hi,
I'm looking into something that seems like an inconsistency in handling
of the CIE pointer in FDEs in .debug_frame, between how debug info is
generated in LLVM and consumed in LLDB.
For FDEs in .eh_frame, the CIE pointer/cie_id field is interpreted as an
offset from the current FDE - this seems to be consistent.
But for cases in .debug_frame, they are treated differently. In LLDB,
the cie_id field is assumed to be relative to the begin of the
.debug_frame section:
https://github.com/llvm/llvm-project/blob/master/lldb/source/Symbol/DWARFCallFrameInfo.cpp#L482-L495
However, when this field is produced in LLVM, it can, depending on
MCAsmInfo flags, end up written as a plain absolute address to the CIE:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCDwarf.cpp#L1699-L1705
That code in MCDwarf.cpp hasn't been touched in many years, so I would
expect that the info it generates actually has been used since and been
found to be correct. Or are most cases built with -funwind-tables or
similar, enabled by default?, so this is exercised in untested cases?
In the case where I'm running in this, LLDB reports "error: Invalid cie
offset" when running executables with such .debug_frame sections.
By adding an ", true" to the end of the EmitSymbolValue call in
MCDwarf.cpp, the symbol reference is made section relative and the code
seems to do what LLDB expects. Is that correct, or should LLDB learn the
cases (which?) where the cie_id is an absolute address instead of a
section relative one?
// Martin
What's the target you're encountering this behavior on? Can you maybe
provide a short example of how the CIE/FDE entries in question look like?
I could be wrong (I'm not really an expert on this), but my
understanding is that "asmInfo->doesDwarfUseRelocationsAcrossSections()"
is basically equivalent to "is target MachO", and the reason that we
don't emit section relative addresses there is because MachO does not
link debug info sections. This means there will only ever be a single
debug_frame contribution in one file, and so we can just put offsets
directly, instead of relying on linker to patch things up. Doing
anything like this in a format which links (concatenates) debug info
sections would certainly result in irreparably corrupted unwind info,
since you have no idea what will be present at a certain absolute
address (offset) once the linker has finished its thing.
That said, if that is all there is here, then it does not seem to me
like there's any special support in lldb needed, as the cie offset will
always be a correct absolute offset from the start of the section by the
time lldb gets to see it (and so it shouldn't matter if the offset was
put there by the compiler or the linker). This makes me think that I am
missing something, but I have no idea what could that be..
Anyway, I hope this helps somehow..
pl
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
