[Lldb-commits] [PATCH] D94064: lldb: Add support for printing variables with DW_AT_ranges on DW_TAG_subprograms

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I don't think that simply setting func_lo_pc to zero will be sufficient to make this work. I would expect this to break in more complicated scenarios (like, even if we just have two of these functions). I think the only reason it works in this case is because for this particular function, it's base address (relative to the CU base) *is* zero.

The purpose of func_lo_pc is pretty weird, but it's essentially used for runtime relocation of location lists within the function -- we take the static "base" of the function, and the runtime "base", and the difference between the two produces the load bias. Applying the same bias to all variable location lists "relocates" the variables. (The reason this is so convoluted is reading location lists straight from (unrelocated) .o files on mac. I seriously considered changing this when working on debug_rnglists, but it turned out it wasn't really necessary, so I let it go.)

The "runtime" function address is being taken in https://github.com/llvm/llvm-project/blob/main/lldb/source/Core/ValueObjectVariable.cpp#L159 (and maybe a couple of other places), and these two things need to be in sync. I think this could just be defined as the first address in the first address range of the function. That should be fine for ELF purposes (I have a feeling this thing would completely break down if macho started rearranging parts of the function), but it does bring up another problem.

LLDB's representation of a function (lldb_private::Function) assumes that all functions will be contiguous (Function::GetAddressRange returns a single range). If we make it so that this range matches the first block of the function (maybe that's what happens now), then maybe we could make things work for the case where DW_AT_ranges are used as a size optimization. However, getting things to work for truly discontinuous functions will require more work...

(Regarding the test, I think we could avoid running a binary by testing this via the "image lookup --verbose" command, and checking that the output contains the variables it should.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94064