Re: [lldb-dev] ELF header does not hold big modules

[Pavel Labath via lldb-dev]

Hello Eugene,

On 21 January 2017 at 00:42, Eugene Birukov  wrote:
> Hello,
>
>
> I have a core dump that LLDB cannot open because it contains more than 64K
> sections. The "readelf" utility gives me the output in the end of this
> message. It seems that the actual number of program headers and the index of
> string table section are written into very first section since they do not
> fit in 16 bits.
>
>
> The "natural" way to deal with this problem would be to change the types of
> fields in ELFHeader struct from 16 to 32 bits (or should I go all the way
> and  do it 64? in case the core dump is bigger than 4GB...) and deal with
> the problem in a single place where we parse the header - the
> ELFHeader::Parse().
>
>
> Objections? Suggestions? Advices?

Sounds like a plan. By "all" I presume you mean "all fields that refer
to section counts or indexes". I don't see a reason the change the
size of the e.g. e_type field. I think going 32 bit will be enough,
particularly as the "fallback" field you are reading this from is only
32 bit wide anyway, and so you would still have to touch this if we
ever cross that boundary. (And we are really talking about 4 billion
sections, not a 4GB core file, right?)


> Hmm... I am not sure that the DataExtractor we pass down there would let me
> read that much past in the file - I have impression that we give only first
> 512 bytes there, but I might be mistaken...

The reason we initially read only the first few bytes of the file, is
to be able to make a quick decision as to whether this is likely to be
a valid elf file (see call to ObjectFileELF::MagicBytesMatch in
GetModuleSpecifications). After that, we extend the buffer to the
whole file. It looks like this currently happens before parsing the
ELF header, but I don't see a reason why  it would have to stay that
way.

cheers,
pavel
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

[Pavel Labath via lldb-dev]

On 20 January 2017 at 18:34, Eugene Birukov  wrote:
> Hello Pavel,
>
>
> Thanks for the reply. Unfortunately I cannot share the core dump with you.
>

No problem, I think this discussion has helped me understand the
problem, and it shouldn't be too hard to reproduce it locally. Now I
just need to find some time to do that. :)

cheers,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Shared Process plugin between Linux and BSD

[Kamil Rytarowski via lldb-dev]

Hello,

For the reference in this thread, I've posted a blog entry on the NetBSD
Foundation site with a summary of the interfaces we were discussing in
this thread:

http://blog.netbsd.org/tnf/entry/summary_of_the_preliminary_lldb

This report covers the topics discussed in this E-mail thread.

I've got some thoughts on redefining current generic interface and
making NativeThreadX optional, but let's see what will happen when we
will get aboard appropriate support for still missing features
(registers' accessors, breakpoints, watchpoints etc).

On 15.12.2016 17:21, Kamil Rytarowski wrote:
> On 15.12.2016 16:08, Pavel Labath wrote:
>> On 15 December 2016 at 14:14, Kamil Rytarowski  wrote:
>>> On 15.12.2016 14:14, Pavel Labath wrote:
>>
>> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
>> add support for it in ptrace(2).
 This value is currently only used in logging code, so we can just
 remove it from the code base. However, it's a useful thing to have for
 the future, so it may be worth making sure the NetBSD kernel supports
 it.

>>>
>>> I was wondering whether waitid(2) or wait6(2) could be used there, as
>>> they return siginfo_t. If so, NetBSD does not need dedicated ptrace(2)
>>> entry.
>>
>> Note that there are two siginfo_t structures in action here. One is
>> the siginfo_t the *inferior* gets as a result of some action (e.g.
>> kill(), raise(), hitting an int3, etc.). The other is the siginfo_t
>> corresponding to the SIGCHLD that the *debugger* gets when something
>> interesting happens to the inferior. (On linux at least ), waitid(2)
>> returns the second one. That one, however, generally does not contain
>> any useful information apart from the process ID. PTRACE_GETSIGINFO
>> returns the first one, and that one contains the interesting stuff
>> (the signal the inferior recieved, and in case of a SIGTRAP, the
>> information about the debug event is encoded there as well). This is
>> usually very important information for the debugger.
>>
>> PTRACE_SETSIGINFO allows you to overwrite the signal that the inferior
>> would receive. It can be used to inject "fake" signals into the
>> inferior. That can be a useful feature from time to time, but
>> currently we do not support that (on linux we support injecting a
>> signal via an argument to PTRACE_CONTINUE, which is a weaker
>> implementation of this call, as it can only inject a signal number,
>> not the full siginfo_t struct). So you may want to implement this at
>> some point, but on the grand scale of things, it's not something very
>> important.
>>
>>
> 
> I see, thank you for your explanation! It looks useful, but let it keep
> for later.
> 

As per-blog entry, there is now an interface for it in NetBSD with
PT_GETSIGINFO and PT_SETSIGINFO.

>>>
>>
>> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
>> equivalent to be implemented.
 Do you mean "implemented in lldb-server" or "implemented in the
 kernel"? Being notified when the inferior exec()s would definitely be
 good. Tracing thread creation and exit is a nice-to-have but low
 priority. The only reason we used it on linux is because that's the
 only way to auto-attach to new threads, but I think that for you that
 will happen automatically.

>>>
>>> I mean implemented in the kernel.
>>>
>>> Thread (lwp) creation and termination is currently detectable in FreeBSD
>>> with a special event, if this is useful in the NetBSD context -- like a
>>> user setting a break on this event explicitly -- I will add it to TODO
>>> list. On NetBSD there is no need to explicitly start tracing new
>>> threads, tracing is per process and it is composed of a bulk of threads
>>> (lwp). POSIX threads are a layer with extra features built upon LWP.
>> BTW, are your debug registers per-process or per-thread? If they are
>> per thread, then you will need to hook thread creation so you can
>> inject the correct watchpoints and stuff, otherwise you will miss some
>> hits. If this is handled by the kernel, then you are probably fine.
>>
> 
> Debug registers (watchpoints) are per-thread (lwp) and they are not
> being inherited on thread's or process' forks. It's a valid use-case.
> 
> I just checked FreeBSD and there is PTRACE_LWP:
> 
> This event flag controls tracing of LWP kernel thread creation and
> destruction. When this event is enabled, new LWPs will stop and report
> an event with PL_FLAG_BORN set before executing their first instruction,
> and exiting LWPs will stop and report an event with PL_FLAG_EXITED set
> before completing their termination.
> 
>>>
>>> There is also the the exect(3) call in our libc inherited from BSD4.2,
>>> but it no longer works in a useful way. It used to singlestep execve(2)
>>> call. I was thinking whether/how to make it useful again, like combine
>>> in it execve(2) + PT_TRACE_ME + SIGSTOP/SIGTRAP on exec.
>>>
>>
>> 4. No tracing of VFORK events implemented.

Re: [lldb-dev] [cfe-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

Hi David,

Please file a bug about the lld issue on http://llvm.org/bugs and mark
it blocking PR31622.

I've merged the clang-tools-extra commit you pointed to in r292834.

Thanks,
Hans

On Fri, Jan 20, 2017 at 10:56 AM, David Abdurachmanov
 wrote:
> Hi,
>
> While building a full stack LLVM/Clang/lld/compiler-rt/clang-tools-extra/
> openmp/etc in a single RPM I hit a couple of issues.
>
> (1)
>
> lld was broken as liblldCOFF.so, liblldDriver.so and liblldELF.so are
> no more installed, but lld binary depends on them.
>
> At first look probably caused by this: https://reviews.llvm.org/D28397
>
> (2)
>
> https://github.com/llvm-mirror/clang-tools-extra/tree/release_40
> Needs 1a15ce4331f4692e7931f07cb3eaf49355ce2c1e from master branch to compile.
>
> Otherwise the builds fails with undefined reference to pthread_create at link 
> time.
>
> Cheers,
> david
>
>> On 20 Jan 2017, at 11:45, Tobias Grosser via cfe-dev 
>>  wrote:
>>
>> Very cool initiative! Thank you!
>>
>> On Fri, Jan 20, 2017, at 10:59 AM, Mehdi Amini via cfe-dev wrote:
>>> Hi,
>>>
>>> FYI, I added a Green dragon job to build and test (stage 1 only right
>>> now) the release branch:
>>> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA-release-4/
>>> 
>>>
>>> —
>>> Mehdi
>>>
 On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
  wrote:

 Dear testers,

 4.0.0-rc1 was just tagged from the branch, with r292377.

 There are still open merge requests and bugs, but I'd like to get the
 testing started to see what issues come up.

 Please build, test, and upload binaries to the sftp. Let me know how
 it goes. I'll upload source, docs, and your binaries to the web site
 once their ready.

 Thanks,
 Hans
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Fri, Jan 20, 2017 at 2:35 PM, Bernhard Rosenkränzer
 wrote:
> Hi,
> updated OpenMandriva packaging. Looks good, so far passes testing on all 4
> supported arches (x86_32, x86_64, armv7hnl, aarch64) after fixing one build
> issue in clang-tools-extra:
>
> FAILED: lib64/libclangIncludeFixerPlugin.so.4.0.0
> : && /usr/bin/clang++  -fPIC -Os  -pipe -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4  -fPIC -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dt
> or -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time
> -std=c++1y -fcolor-diagnostics -ffunction-sections -fdata-sections
> -fno-common -Woverloaded-virtual -Wno-nested-anon-types -Os  -pipe -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector
> --param=ssp-buffer-size=4  -fPIC  -L/home/bero/abf/llvm/BUIL
> D/llvm-4.0.0.src/build/lib64 -Wl,-z,defs   -Wl,-O3 -Wl,--gc-sections -shared
> -Wl,-soname,libclangIncludeFixerPlugin.so.4.0 -o
> lib64/libclangIncludeFixerPlugin.so.4.0.0
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o
> lib64/libclangAST.so.4.0.0 lib64/libclangBasic.so.4.0.
> 0 lib64/libclangFrontend.so.4.0.0 lib64/libclangIncludeFixer.so.4.0.0
> lib64/libclangParse.so.4.0.0 lib64/libclangSema.so.4.0.0
> lib64/libclangTooling.so.4.0.0 lib64/libLLVMSupport.so.4.0.0 && :
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:/home/bero/abf/llvm/BUILD/llvm-4.0.0.src/tools/clang/tools/extra/include-fixer/plugin/IncludeFixerPlugin.cpp:function
> std::thread::thread  std::default_delete > ()> ()>,
> std::unique_ptr std::default_delete >
>>::_Async_state_impl(std::_Bind_simple std::default_delet
> e > ()>
> ()>&&)::{lambda()#1}>(std::__future_base::_Async_state_impl std::default_delete > ()> ()>,
> std::unique_ptr std::default_delete clude_fixer::SymbolIndex> >
>>::_Async_state_impl(std::_Bind_simple std::default_delete > ()>
> ()>&&)::{lambda()#1}&&): error: undefined reference to 'pthread_create'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ninja: build stopped: subcommand failed.
>
> Patch for this issue is attached (but will likely break Windows builds -
> probably needs a platform check added).

Benjamin landed that fix in r291892 which was just merged, so
hopefully that's all good now.

Thanks,
Hans


> On 18 January 2017 at 16:45, Hans Wennborg via Release-testers
>  wrote:
>>
>> Dear testers,
>>
>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>
>> There are still open merge requests and bugs, but I'd like to get the
>> testing started to see what issues come up.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> it goes. I'll upload source, docs, and your binaries to the web site
>> once their ready.
>>
>> Thanks,
>> Hans
>> ___
>> Release-testers mailing list
>> release-test...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [4.0.0 Release] Release Candidate 1 source and binaries available

[Hans Wennborg via lldb-dev]

Source, binaries and docs for LLVM-4.0.0-rc1 are now available at
http://www.llvm.org/pre-releases/4.0.0/#rc1

Please try it out, run tests, build your favourite projects and file
bugs about anything that doesn't work and needs to be fixed before the
release, marking them as blockers of http://llvm.org/pr31622.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] ELF header does not hold big modules

[Eugene Birukov via lldb-dev]

> By "all" I presume you mean "all fields that refer to section counts or 
> indexes".


Correct. I mean exactly 3 fields: e_phnum, e_shnum, and e_shstrndx that could 
be redirected to section #0.


Sent from Outlook



From: Pavel Labath 
Sent: Monday, January 23, 2017 2:04 AM
To: Eugene Birukov
Cc: LLDB
Subject: Re: ELF header does not hold big modules

Hello Eugene,

On 21 January 2017 at 00:42, Eugene Birukov  wrote:
> Hello,
>
>
> I have a core dump that LLDB cannot open because it contains more than 64K
> sections. The "readelf" utility gives me the output in the end of this
> message. It seems that the actual number of program headers and the index of
> string table section are written into very first section since they do not
> fit in 16 bits.
>
>
> The "natural" way to deal with this problem would be to change the types of
> fields in ELFHeader struct from 16 to 32 bits (or should I go all the way
> and  do it 64? in case the core dump is bigger than 4GB...) and deal with
> the problem in a single place where we parse the header - the
> ELFHeader::Parse().
>
>
> Objections? Suggestions? Advices?

Sounds like a plan. By "all" I presume you mean "all fields that refer
to section counts or indexes". I don't see a reason the change the
size of the e.g. e_type field. I think going 32 bit will be enough,
particularly as the "fallback" field you are reading this from is only
32 bit wide anyway, and so you would still have to touch this if we
ever cross that boundary. (And we are really talking about 4 billion
sections, not a 4GB core file, right?)


> Hmm... I am not sure that the DataExtractor we pass down there would let me
> read that much past in the file - I have impression that we give only first
> 512 bytes there, but I might be mistaken...

The reason we initially read only the first few bytes of the file, is
to be able to make a quick decision as to whether this is likely to be
a valid elf file (see call to ObjectFileELF::MagicBytesMatch in
GetModuleSpecifications). After that, we extend the buffer to the
whole file. It looks like this currently happens before parsing the
ELF header, but I don't see a reason why  it would have to stay that
way.

cheers,
pavel
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Navigating STL types

[Andreas Yankopolus via lldb-dev]

How can I navigate STL types using their overloaded operators and member 
functions (e.g., “[]” and “.first()” for vectors) ? For example, take a C++ 
source file with:

std::vector v;
v.push_back("foo”);

Breaking after this statement in lldb and typing "p v[0]" would be reasonably 
expected to return "foo", but it gives a symbol lookup error. Similarly, “p 
v.first()” gives an error that there’s no member named “first”. I’m seeing this 
issue with clang/llvm 3.9 and 4.0 nightlies on Ubuntu 16.10 and with Apple’s 
versions on MacOS Sierra.

Internet rumor (e.g., this discussion 
)
 says this is aggressive inlining of STL code. I’m compiling in clang++ with 
“-O0 -g -glldb”.

In comparison, gdb prints the value of v[0] just fine when compiled with gdb.

What am I doing wrong?___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Navigating STL types

[Mehdi Amini via lldb-dev]

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.

— 
Mehdi

> On Jan 23, 2017, at 3:58 PM, Andreas Yankopolus via lldb-dev 
>  wrote:
> 
> How can I navigate STL types using their overloaded operators and member 
> functions (e.g., “[]” and “.first()” for vectors) ? For example, take a C++ 
> source file with:
> 
> std::vector v;
> v.push_back("foo”);
> 
> Breaking after this statement in lldb and typing "p v[0]" would be reasonably 
> expected to return "foo", but it gives a symbol lookup error. Similarly, “p 
> v.first()” gives an error that there’s no member named “first”. I’m seeing 
> this issue with clang/llvm 3.9 and 4.0 nightlies on Ubuntu 16.10 and with 
> Apple’s versions on MacOS Sierra.
> 
> Internet rumor (e.g., this discussion 
> )
>  says this is aggressive inlining of STL code. I’m compiling in clang++ with 
> “-O0 -g -glldb”.
> 
> In comparison, gdb prints the value of v[0] just fine when compiled with gdb.
> 
> What am I doing wrong?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Tab completion for variable names, etc.

[Andreas Yankopolus via lldb-dev]

Does lldb support tab completion of variable or class/method names? If so, how 
is it enabled? Command completion works just fine with lldb 3.9 on Ubuntu 16.10 
and with Apple’s version on MacOS Sierra. But if I define 
"std::vector v;" in a C++ source file, break lldb after this 
definition, and type “print v.” followed by hitting the tab key, nothing 
happens. In gdb, this lists member functions such as “front”, “back”, etc.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Navigating STL types

[Andreas Yankopolus via lldb-dev]

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
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Tab completion for variable names, etc.

[Jim Ingham via lldb-dev]

This is a long-standing missing feature in lldb.  We delegate to clang the 
parsing of expressions, so we're going to have to either create a separate 
parser for symbol completion or figure out how to get clang to parse up to the 
cursor and then tell us what it has parsed so far.  This would be a great 
project for somebody to take on, if anybody has some spare time on their hands!

Jim


> On Jan 23, 2017, at 4:09 PM, Andreas Yankopolus via lldb-dev 
>  wrote:
> 
> Does lldb support tab completion of variable or class/method names? If so, 
> how is it enabled? Command completion works just fine with lldb 3.9 on Ubuntu 
> 16.10 and with Apple’s version on MacOS Sierra. But if I define 
> "std::vector v;" in a C++ source file, break lldb after this 
> definition, and type “print v.” followed by hitting the tab key, nothing 
> happens. In gdb, this lists member functions such as “front”, “back”, etc.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Navigating STL types

[Mehdi Amini via lldb-dev]

> On Jan 23, 2017, at 4:13 PM, Andreas Yankopolus  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?

Long time overdue, keep being punted because other higher priorities issues 
keep showing up, “soon” hopefully.

> Seems like being able to navigate STL types would be a useful thing.

I don’t think anyone would disagree :)

— 
Mehdi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Navigating STL types

[Jim Ingham via lldb-dev]

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 and:

(lldb) expr my_vec
(std::__1::vector >) $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]
0x0001002000e4: (int) my_vec[5] = 5
(lldb) expr printf("%d\n", *((int *) 0x0001002000e4))
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;

in your C++ sources somewhere (replace std::vector 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 >::size_type) $0 = 10
(lldb) expr my_vec[5]
(std::__1::__vector_base >::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 
>  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
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev