[Lldb-commits] [PATCH] D71487: [LLDB] Fix address computation for member function linked with lld

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

This definitely needs a more targeted fix. Requiring a symbol is not good, and it will be particularly problematic on windows, as there we don't have the equivalent of a .symtab (only .dynsym).

Looking at your example, I'm pretty sure that the DW_AT_object_pointer business is a red herring. That's just the normal way of describing member functions -- you first describe the interface of the function withing the containing DW_TAG_structure_type, and then you (outside of the struct) define the precise details of the method (code location, etc.). The second definition references the first one via DW_AT_specification, and lldb should already know how to read these things -- if not then a fix needs to be made there. But I don't think that's necessary, because the choice of linker should not impact this.

What I actually think is happening is that there are *two* definitions of the "four" function (because its an inline function used from two compilation units). This means the linker has to merge them, but unfortunately it cannot also "merge" the debug info (this is a long standing problem with dwarf). So, what the linker does is set the DW_AT_low_pc of the function which got dropped to zero. Lldb does not detect this, and so it ends up trying to call the address zero, and the expression crashes.

The reason that the choice of linker matters here is because they have different behavior regarding which copy gets dropped, and lld seems to drop the one which lldb tries first. This is also why your fix kind of works -- because there is no symbol at address zero (usually).

So, I think the fix for this should be in DWARF code, to make sure these kinds of functions don't even get considered. Somewhere in SymbolFileDWARF::FindFunctions, or maybe even deeper. One way to detect these stripped functions would be to check that the purported address of the function actually lies within the boundaries of one of the sections of the object file.

After that, we can probably come up with a simpler way to test this too...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71487/new/

https://reviews.llvm.org/D71487