I'm seeing particular globals spuriously being reported as local variables:
they're returned by SBFrame::GetVariables(true, true, false, true) because
their scope is eValueTypeVariableLocal.
I've tracked down the problem but don't know DWARF well enough to determine
the right fix. Anyone want to help me out?
--
I can reproduce with the following program:
struct Obj{};
namespace N { extern Obj& o; }
using N::o;
int main(){}
When building with clang -g, lldb gives
(lldb) frame v -g -s
LOCAL: (Obj &) N::o = <no location, value may have been optimized out>
(lldb) target v -s
LOCAL: (Obj &) N::o = <no location, value may have been optimized out>
It seems confused about whether it's local or global.
readelf --dump-debug has the following info for the variable:
<2><31>: Abbrev Number: 3 (DW_TAG_variable)
<32> DW_AT_name : (indirect string, offset: 0x51): o
<36> DW_AT_type : <0x42>
<3a> DW_AT_external : 1
<3a> DW_AT_decl_file : 1
<3b> DW_AT_decl_line : 2
<3c> DW_AT_declaration : 1
<3c> DW_AT_location : 0 byte block: ()
<3d> DW_AT_linkage_name: (indirect string, offset: 0x57): _ZN1N1oE
It seems that the zero-length location is a problem: SymbolFileDWARF.cpp
thinks a variable without a valid location must be static or local.
FWIW, gdb on the clang-built binary shows N::o as an optimized-out global,
which seems fine. gcc generates debug info that omits the DW_AT_location,
which causes gdb to hide it completely I think.
Cheers, Sam
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
