lldb has "synthetic child providers" for most of the STL collection types, so
we do show all the child values, for instance my_vec is a std::vector<int> and:
(lldb) expr my_vec
(std::__1::vector<int, std::__1::allocator<int> >) $0 = size=10 {
[0] = 0
[1] = 1
[2] = 2
[3] = 3
[4] = 4
[5] = 5
[6] = 6
[7] = 7
[8] = 8
[9] = 9
}
Those values were printed by the std::vector data formatter. To learn more
about data formatters, see:
http://lldb.llvm.org/varformats.html
You can access individual members of the array using the "frame variable"
command, which prints local variables & arguments it looks up by name in the
debug info:
(lldb) frame variable my_vec[5]
(int) my_vec[5] = 5
You can't do that using the "print" command, because it will actually try to
run this as an expression, which fails without the accessor functions.
OTOH, the "frame variable" command doesn't run real expressions, it just looks
up the variable by name and then accesses the synthetic children that the data
formatter provides. But for many things this works well enough to get you
going. You can combine "frame var" with the -L option and the expression
parser if you need to pass a particular element to some function:
(lldb) frame variable -L my_vec[5]
0x00000001002000e4: (int) my_vec[5] = 5
(lldb) expr printf("%d\n", *((int *) 0x00000001002000e4))
5
(int) $1 = 2
That's not ideal, for sure, and it will be great when the STL leaves all these
functions around for the debugger at -O0. But you can usually get your hands
on what you need this way...
BTW, another even more horrible trick when you are desperate is to put:
template class std::vector<int>;
in your C++ sources somewhere (replace std::vector<int> with the instantiation
you need to print.) That will cause clang to emit a full copy of the template
instantiation in your binary, and then everything works as expected:
(lldb) expr my_vec.size()
(std::__1::vector<int, std::__1::allocator<int> >::size_type) $0 = 10
(lldb) expr my_vec[5]
(std::__1::__vector_base<int, std::__1::allocator<int> >::value_type) $1 = 5
etc. Obviously, this isn't a great long-term solution, but if you can afford
the time to rebuild it does get the job done.
Jim
> On Jan 23, 2017, at 4:13 PM, Andreas Yankopolus via lldb-dev
> <[email protected]> wrote:
>
> Mehdi,
>
>> Yes, this is a problem with our STL, we are forcing inlining and we need to
>> fix this on libc++ side, it is scheduled, but we haven’t come to it yet.
>
> Any guesstimate as to the timeframe? Seems like being able to navigate STL
> types would be a useful thing.
>
> Thanks,
>
> Andreas
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
