[lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame

[Pavel Labath via lldb-dev]

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