Re: [lldb-dev] Navigating STL types

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

Re: [lldb-dev] Navigating STL types

> 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

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

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

Re: [lldb-dev] Navigating STL types

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] Tab completion for variable names, etc.

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

Re: [lldb-dev] Navigating STL types

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

[lldb-dev] Navigating STL types

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

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

> 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

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

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

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

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

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

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

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

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.

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

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

Re: [lldb-dev] 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