Re: [lldb-dev] Is it ok to use lldb_private from the driver?

[Jim Ingham via lldb-dev]

The driver used to have a bunch of lldb_private stuff in it, mostly to run the 
event loop, which Greg abstracted into SB API’s a while ago.  If it can be 
avoided, I’d rather not add it back in.  Our claim is folks should be able to 
write their own debugger interfaces (command line or gui) using the SB API’s, 
so it would be good if we stuck to that discipline as well.

I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.

Jim

> On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I notice everything uses SB classes only.  Is this a hard requirement?  We 
> have a bit of cruft in all of the top-level executables (lldb-server, 
> lldb-mi, lldb) that could be shared if we could move it into Host, but then 
> the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi 
> and lldb-server already do this, it's only lldb that doesn't.  Is this ok?
> 
> If not, I can always add a method to SBHostOS and just not add a 
> corresponding swig interface definition for it (so it wouldn't be accessible 
> from Python), which would achieve basically the same effect.
> ___
> 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] Missed breakpoint

[Greg Clayton via lldb-dev]

The only similar case we ran into was a situation where our kernel was playing 
tricks and essentially re-loading a module at the same location. So what would 
happen is:

1 - kernel would load a.out's .text section at 0x1
2 - LLDB would notice via a module loaded notification and would set a 
breakpoint at 0x1 + offset
3 - kernel would load a.out's .text section at 0x1 but erase all changes, 
like the breakpoint we set above in step 2
4 - We would get a load notification for a.out's .text section again, but we 
would see that the location didn't change, so the module doesn't send out a 
module loaded notification and we would lose the breakpoint for good

What our dynamic loader had to do was to know that this can happen and if you 
get a load notification for a section, send a module unloaded for a.out first 
(which would clear the breakpoint), and then send out a module loaded 
notification and the breakpoint would get set correctly once again when the 
section was reloaded.

Greg Clayton

> On Mar 18, 2016, at 11:59 AM, Dean De Leo via lldb-dev 
>  wrote:
> 
> Hi,
> 
> we have been observing that, sporadically, an internal callback set for a 
> breakpoint is not invoked. We are setting an hidden breakpoint in the 
> renderscript plugin through:
> 
> breakpoint = target.CreateBreakpoint(symbol_address, true, false);
> breakpoint->SetCallback(rs_callback, rs_baton, true);
> 
> where symbol_address refers to a runtime function x in the debugged process.
> The callback is properly invoked 99% of the time that the process calls the 
> function x, though occasionally it is missed, while both prior and further 
> calls are recorded.
> 
> This issue seems to occur only in android/mips32, though we are not able to 
> exclude whether other platforms are affected.
> 
> Has anyone experienced a similar issue or can provide any suggestion to what 
> might be worth to watch for that might cause this behaviour?
> 
> Thanks,
> Dean
> 
> -- 
> Codeplay Software Ltd
> Level C, Argyle House
> 3 Lady Lawson Street, Edinburgh, EH3 9DR
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
> 
> ___
> 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] Is it ok to use lldb_private from the driver?

[Jim Ingham via lldb-dev]

If I were writing a Pure Python interface to lldb, could I use the Python 
signal facilities to abstract the functionality you are trying to abstract 
through Host::Signal?  If so, then I’d have no objection to only doing it in 
the C++ API’s (maybe with a note to that effect in the headers.)

If not, as long as what you are doing didn’t preclude somebody implementing a 
Python version later if they were sufficiently motivated, I don’t think it 
would be a requirement on you to do it now.

Jim

> On Mar 18, 2016, at 10:20 AM, Zachary Turner  wrote:
> 
> Is it ok to add a public API that isn't interfaced to Python?  In this case 
> the culprit is the signal() function.  Windows doesn't really support signal 
> in the same way that other platforms do, so there's some code in each driver 
> that basically defines a signal function, and then if you're unlucky when you 
> build, or accidentally include the wrong header file (even indirectly), 
> you'll get multiply defined symbol errors.
> 
> So what I wanted to do was make a Host::Signal() that on Windows had our 
> custom implementation, and on other platforms just called signal.  But it 
> returns and accepts function pointers, and making this work through the 
> python api is going to be a big deal, if not flat out impossible.
> 
> The idea is that instead of writing signal() everywhere, we would write 
> lldb_private::Host::Signal() everywhere instead.  
> 
> On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham  > wrote:
> The driver used to have a bunch of lldb_private stuff in it, mostly to run 
> the event loop, which Greg abstracted into SB API’s a while ago.  If it can 
> be avoided, I’d rather not add it back in.  Our claim is folks should be able 
> to write their own debugger interfaces (command line or gui) using the SB 
> API’s, so it would be good if we stuck to that discipline as well.
> 
> I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.
> 
> Jim
> 
> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > I notice everything uses SB classes only.  Is this a hard requirement?  We 
> > have a bit of cruft in all of the top-level executables (lldb-server, 
> > lldb-mi, lldb) that could be shared if we could move it into Host, but then 
> > the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi 
> > and lldb-server already do this, it's only lldb that doesn't.  Is this ok?
> >
> > If not, I can always add a method to SBHostOS and just not add a 
> > corresponding swig interface definition for it (so it wouldn't be 
> > accessible from Python), which would achieve basically the same effect.
> > ___
> > 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] Help needed regarding LLDB/MI

[Jim Ingham via lldb-dev]

Please file bugs where the lldb implementation of the MI doesn't support 
features documented in the GDB MI documentation.

Jim

> On Mar 16, 2016, at 11:01 AM, RISHABH GUPTA via lldb-dev 
>  wrote:
> 
> 2.-var-update command ,In GDB/MI "-var-update *" works fine  but the same 
> command in LLDB/MI gives 
> "^error,msg="Command 'var-update'. Variable '*' does not exist"
> 
> So it takes time to figure out the correct usage of the command 
> 
> 
> 

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

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jeffrey Tan via lldb-dev]

Seems like the crashes happens because of abi::__cxa_demangle() for mangled
symbol name "
_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect
".

This is blocking us from releasing our C++ debugging support. Anyone know
of a quick workaround I can fix it locally? Thanks!

On Thu, Mar 17, 2016 at 12:25 PM, via lldb-dev 
wrote:

> Bug ID 26978 
> Summary LLDB stack overflow while dealing with symbols for a process on
> Linux
> Product lldb
> Version 3.8
> Hardware PC
> OS Linux
> Status NEW
> Severity release blocker
> Priority P
> Component All Bugs
> Assignee lldb-dev@lists.llvm.org
> Reporter jeffrey.fu...@gmail.com
> CC llvm-b...@lists.llvm.org
> Classification Unclassified
>
> While using lldb to attach a process in our company on Linux, lldb segment
> fault with a huge stack(more than 30K stack frames). I assume it crashes
> because of stack overflow. Let me know what additional information you 
> needed(I
> have coredump):
>
> #0  0x7f28ce530819 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724b80) at cp-demangle.c:4286
> #1  0x7f28ce5321e6 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724bb0) at cp-demangle.c:4324
> #2  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2724c10) at cp-demangle.c:4324
> #3  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724c70) at cp-demangle.c:4489
> #4  0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2724c88) at cp-demangle.c:4923
> #5  0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2724ca0) at cp-demangle.c:4493
> #6  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2724cd0) at cp-demangle.c:4324
> #7  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2725030) at cp-demangle.c:4489
> #8  0x7f28ce535353 in d_print_mod (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mod=) at cp-demangle.c:5539
> #9  0x7f28ce535dbe in d_print_mod_list (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mods=mods@entry=0x7f28c1f2ba30,
> suffix=suffix@entry=0) at cp-demangle.c:5468
> #10 0x7f28ce5366a1 in d_print_function_type (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mods=0x7f28c1f2ba30, dc=0x7f28c2725138) at
> cp-demangle.c:5609
> #11 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725138) at cp-demangle.c:4808
> #12 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2725150) at cp-demangle.c:4434
> #13 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27251b0) at cp-demangle.c:4324
> #14 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
> #15 0x7f28ce534448 in d_print_comp (dpi=0x7f28c2728c00, options= out>, dc=0x7f28c2725270) at cp-demangle.c:4793
> #16 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725288) at cp-demangle.c:4923
> #17 0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c27252a0) at cp-demangle.c:4493
> #18 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27252d0) at cp-demangle.c:4324
> #19 0x7f28ce534448 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4793
> #20 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c2725330) at cp-demangle.c:4434
> #21 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725390) at cp-demangle.c:4324
> #22 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27253a8) at cp-demangle.c:4742
> #23 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c27253c0) at cp-demangle.c:4742
> #24 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
> #25 0x7f28ce53123b in d_print_comp (dpi=0x7f28c2728c00, options=17,
> dc=0x7f28c27252e8) at cp-demangle.c:4742
> #26 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, dc=0x7f28c2725300) at cp-demangle.c:4923
> #27 0x7f28ce5366e1 in d_print_function_type (dpi=dpi@entry=0x7f28c2728c00,
> options=options@entry=17, mods=0x7f28c1f2cc70, dc=0x7f28c2725318) at
> cp-demangle.c:5617
> #28 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f

[lldb-dev] Embedding lldb[server] in a CPU simulator

[Tyro Software via lldb-dev]

I have a simulator for a custom ["toy"] CPU running on Linux, to which I
want to add at least basic debugging support (e.g. stepping instructions,
reading/writing registers and memory), then driving this from lldb over a
local TCP socket.

I could implement this as a custom socket server handling the GDB Remote
Serial Protocol, like GDB server stubs that I've seen. But probably there's
already a suitable interface and library in LLDB for this, e.g. providing
the RSP parsing and basic state maintennce with callbacks/virtuals for the
target-specific actions?

Thanks for any guidance (and apologies that I'm probably using terminology
like "server" incorrectly and so overlooking the existing documentation)

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

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Kate Stone via lldb-dev]

The cxa_demangle implementation definitely consumes stack aggressively, 
especially when compiled -O0.  I’d definitely recommend an 8MB+ stack for any 
thread that may wind up demangling arbitrary C++ symbols.  The new “fast 
demangler” is much more conservative with stack space but doesn’t yet support 
the full name mangling specification, so complex symbols often rely on falling 
back to cxa_demangle.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Mar 17, 2016, at 2:19 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Make stacks bigger when making threads on linux?
> 
>> On Mar 17, 2016, at 1:39 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Seems like the crashes happens because of abi::__cxa_demangle() for mangled 
>> symbol name " 
>> _ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect".
>> 
>> This is blocking us from releasing our C++ debugging support. Anyone know of 
>> a quick workaround I can fix it locally? Thanks!
>> 
>> On Thu, Mar 17, 2016 at 12:25 PM, via lldb-dev  
>> wrote:
>> Bug ID   26978
>> Summary  LLDB stack overflow while dealing with symbols for a process on 
>> Linux   
>> Product  lldb
>> Version  3.8
>> Hardware PC
>> OS   Linux
>> Status   NEW
>> Severity release blocker
>> Priority P
>> ComponentAll Bugs
>> Assignee lldb-dev@lists.llvm.org
>> Reporter jeffrey.fu...@gmail.com
>> CC   llvm-b...@lists.llvm.org
>> Classification   Unclassified
>> 
>> While using lldb to attach a process in our company on Linux, lldb segment
>> fault with a huge stack(more than 30K stack frames). I assume it crashes
>> because of stack overflow. Let me know what additional information you 
>> needed(I
>> have coredump):
>> 
>> #0  0x7f28ce530819 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724b80) at cp-demangle.c:4286
>> #1  0x7f28ce5321e6 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724bb0) at cp-demangle.c:4324
>> #2  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c10) at cp-demangle.c:4324
>> #3  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724c70) at cp-demangle.c:4489
>> #4  0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c88) at cp-demangle.c:4923
>> #5  0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724ca0) at cp-demangle.c:4493
>> #6  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724cd0) at cp-demangle.c:4324
>> #7  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725030) at cp-demangle.c:4489
>> #8  0x7f28ce535353 in d_print_mod (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mod=) at cp-demangle.c:5539
>> #9  0x7f28ce535dbe in d_print_mod_list (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=mods@entry=0x7f28c1f2ba30,
>> suffix=suffix@entry=0) at cp-demangle.c:5468
>> #10 0x7f28ce5366a1 in d_print_function_type 
>> (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=0x7f28c1f2ba30, dc=0x7f28c2725138) at
>> cp-demangle.c:5609
>> #11 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725138) at cp-demangle.c:4808
>> #12 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725150) at cp-demangle.c:4434
>> #13 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27251b0) at cp-demangle.c:4324
>> #14 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
>> #15 0x7f28ce534448 in d_print_comp (dpi=0x7f28c2728c00, 
>> options=> out>, dc=0x7f28c2725270) at cp-demangle.c:4793
>> #16 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725288) at cp-demangle.c:4923
>> #17 0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c27252a0) at cp-demangle.c:4493
>> #18 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27252d0) at cp-demangle.c:4324
>> #19 0x7f28ce534448 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4793
>> #20 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725330) at cp-demangle.c:4434
>> #21 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725390) at cp-demangle.c:4324
>> #22 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@en

Re: [lldb-dev] Embedding lldb[server] in a CPU simulator

[Greg Clayton via lldb-dev]

> On Mar 17, 2016, at 5:01 AM, Tyro Software via lldb-dev 
>  wrote:
> 
> I have a simulator for a custom ["toy"] CPU running on Linux, to which I want 
> to add at least basic debugging support (e.g. stepping instructions, 
> reading/writing registers and memory), then driving this from lldb over a 
> local TCP socket. 
> 
> I could implement this as a custom socket server handling the GDB Remote 
> Serial Protocol, like GDB server stubs that I've seen. But probably there's 
> already a suitable interface and library in LLDB for this, e.g. providing the 
> RSP parsing and basic state maintennce with callbacks/virtuals for the 
> target-specific actions?
> 
We have classes you can use to receive the packets. See the 
GDBRemoteCommunicationServerLLGS class. This is the "LLDB GDB server" class. It 
uses classes whose type is:

class NativeBreakpoint;
class NativeBreakpointList;
class NativeProcessProtocol;
class NativeRegisterContext;
class NativeThreadProtocol;
class UnixSignals;

You would subclass these and fill them in similar to what the linux 
implementations are doing.


> Thanks for any guidance (and apologies that I'm probably using terminology 
> like "server" incorrectly and so overlooking the existing documentation)

Let me know if the above info makes sense and feel free to ask any questions.

Greg

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

Re: [lldb-dev] Help needed regarding LLDB/MI

[RISHABH GUPTA via lldb-dev]

On Wed, Mar 16, 2016 at 10:13 PM, Ted Woodward 
wrote:

> Hi Rishabh,
>
>
>
Hi Ted,

> It looks like you’re trying to use lldb commands when running lldb-mi.
> lldb-mi is the gdb-mi command layer on top of lldb, primarily used by tools
> like Eclipse to talk to lldb or gdb using a similar command set. These
> commands are documented here:
> https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html .
>
>
>
I was aware that commands like "n","list" are all Non MI commands .I  was
actually looking for their corresponding commands for which I found
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html#GDB_002fMI  page
more helpful.
Thanks :)


> If you’re interested in running the lldb command line debugger, don’t
> start MI, but just lldb, with “lldb”.
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of 
> *RISHABH
> GUPTA via lldb-dev
> *Sent:* Friday, March 11, 2016 11:30 AM
> *To:* lldb-dev@lists.llvm.org
> *Subject:* [lldb-dev] Help needed regarding LLDB/MI
>
>
>
> Hello all,
>
> I have started using LLDB/MI but there are some commands that are not
> working .I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then
> launch the application that  I want to debug but commands like "n"
> ,"list","continue" ,"step" are not working.There is this error message that
> gets displayed on giving these commands
>
> "^error,msg="Driver. Received command 'command_name'. It was not handled.
> Command 'continue' not in Command Factory"
>
> I tried looking for  the substitutes of these commands here
> https://github.com/llvm-mirror/lldb/tree/7535162178eada833e72a5525fc26dcc04e7331e/tools/lldb-mi
> but could not find any.
>
> Could anyone please help me out with this?
>
> Thank you :)
>
> Rishabh
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] unable to build lldb 3.8

[Peter Steinbach via lldb-dev]

Dear all,

as a follow-up, are there any plans to make lldb support CUDA, OpenCL or 
SPIR-V based platforms in the near future?


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

Re: [lldb-dev] exception "leaks" to debugger for win32

[Greg Clayton via lldb-dev]

Anything exception that is done by the implementation in order to implement 
normally stopping at the entry point should be covered up and not sent to the 
user. A thread has the notion of a private stop info and one that is produced 
for the public consumption. If this exception is indeed only showing up because 
this is the way we were able to stop at the entry point, we should not be 
showing that to the user.

> On Mar 18, 2016, at 11:24 AM, Carlo Kok via lldb-dev 
>  wrote:
> 
> When starting a process on Win32 there's an internal exception (breakpint) 
> that leaks to the debug caller:
> s 'Exception 0x8003 encountered at address 0x7789ccbc'#0
> 
> This one is dealt with by the debugger internally but there's still a 
> StateType.eStateStopped event for it. On other platforms there's no exception 
> like this for the internal start breakpoint (note that actual breakpoints 
> after this hit just fine)
> 
> -- 
> Carlo Kok
> RemObjects Software
> ___
> 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] "target modules load" and breakpoints not working correctly

[Greg Clayton via lldb-dev]

Sounds like something is going wrong when resolving the address. I am guessing 
that your sections got unloaded when you attached to your GDB remote target. So 
try this:

(lldb) file u:\lldb_test\dlopen
Current executable set to 'u:\lldb_test\dlopen' (hexagon).
(lldb) target modules load -f dlopen -s 0x2
(lldb) b main
Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018

Note we got the address correct. Now do a:

(lldb) image dump sections dlopen

Check to make sure all addresses for the sections look good.

Now do:

(lldb) gdb-remote tedwood-ubuntu:5556
(lldb) image dump sections dlopen

I am guessing that the sections have been moved...

Let me know what you find.

> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I’m seeing 2 issues with “target modules load”:
>  
>  
>  
> Issue #1: load address is forgotten after a connect:
>  
> (lldb) file u:\lldb_test\dlopen
> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
> (lldb) target modules load -f dlopen -s 0x2
> (lldb) b main
> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018
> (lldb) gdb-remote tedwood-ubuntu:5556
>  
> But it’s set the breakpoint at 0x10018 instead of 0x30018:
> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address = 0x10018
> <  14> send packet: $Z0,10018,4#10
> <   4> read packet: $#00
> Software breakpoints are unsupported
> <  14> send packet: $Z1,10018,4#11
> <   6> read packet: $OK#9a
>  
> (lldb) br l
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
> resolved, hit count = 0
>  
>  
>  
>  
> Issue #2: breakpoints on the remote server aren’t updated with a new load 
> address, even though they’re updated in the breakpoint list:
>  
> (lldb) br l
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
> resolved,
> hit count = 0
>  
> (lldb) target modules load -f dlopen -s 0x2
> (lldb) br l
> <   7> send packet: $p29#db
> <  12> read packet: $0010#81
> <   7> send packet: $p1d#05
> <  12> read packet: $#80
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
> resolved,
> hit count = 0
>  
> (lldb) c
> Process 1 stopped
> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 
> 24
> at dlopen.c:26, stop reason = breakpoint 1.1
> frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at 
> dlopen.c:26
>  
> (lldb) re r pc
>   pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>  
> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 
> 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a Z 
> packet to add one at 0x30018.
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> ___
> 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] exception "leaks" to debugger for win32

[Zachary Turner via lldb-dev]

FWIW all the debuggers that people normally use on windows show it this way
as well.  The reason is that by default, if you do nothing and simply
launch a program under a debugger, you hit a breakpoint.  There's no way to
avoid it, it's done by the loader at the OS level.  If someone doesn't want
to stop at entry point (e.g. doesn't specify -s), we go out of our way to
mask it.  So seeing that a breakpoint was hit on startup, while not
consistent with LLDB on other platforms, is consistent with other debuggers
on Windows.  For example, on WinDbg, I get this:

CommandLine: D:\infinite.exe
Symbol search path is: *** Invalid ***

* Symbol loading may be unreliable without a symbol search path.   *
* Use .symfix to have the debugger choose a symbol path.   *
* After setting your symbol path, use .reload to refresh symbol locations. *

Executable search path is:
ModLoad: 0094 009f8000   infinite.exe
ModLoad: 770e 7725b000   ntdll.dll
ModLoad: 7457 7465   C:\WINDOWS\SysWOW64\KERNEL32.DLL
ModLoad: 747a 7491e000   C:\WINDOWS\SysWOW64\KERNELBASE.dll
ModLoad: 723e 72472000   C:\WINDOWS\SysWOW64\apphelp.dll
ModLoad: 743e 7445b000   C:\WINDOWS\SysWOW64\ADVAPI32.dll
ModLoad: 760b 7616e000   C:\WINDOWS\SysWOW64\msvcrt.dll
ModLoad: 7446 744a4000   C:\WINDOWS\SysWOW64\sechost.dll
ModLoad: 7600 760ad000   C:\WINDOWS\SysWOW64\RPCRT4.dll
ModLoad: 73e1 73e2e000   C:\WINDOWS\SysWOW64\SspiCli.dll
ModLoad: 73e0 73e0a000   C:\WINDOWS\SysWOW64\CRYPTBASE.dll
ModLoad: 74a8 74ad8000   C:\WINDOWS\SysWOW64\bcryptPrimitives.dll
(acc0.9894): Break instruction exception - code 8003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
ntdll.dll -
eax= ebx=0003 ecx=eaea edx= esi=009400f8
edi=0029e000
eip=7718ccbc esp=0018f4e4 ebp=0018f510 iopl=0 nv up ei pl zr na pe
nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b
efl=0246
ntdll!LdrInitShimEngineDynamic+0x6dc:
7718ccbc cc  int 3


Then you have to manually continue to skip this.  But it's still an int 3
and shows up in the debugger no different than any other int 3 to the user.

On Fri, Mar 18, 2016 at 11:36 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Anything exception that is done by the implementation in order to
> implement normally stopping at the entry point should be covered up and not
> sent to the user. A thread has the notion of a private stop info and one
> that is produced for the public consumption. If this exception is indeed
> only showing up because this is the way we were able to stop at the entry
> point, we should not be showing that to the user.
>
> > On Mar 18, 2016, at 11:24 AM, Carlo Kok via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > When starting a process on Win32 there's an internal exception
> (breakpint) that leaks to the debug caller:
> > s 'Exception 0x8003 encountered at address 0x7789ccbc'#0
> >
> > This one is dealt with by the debugger internally but there's still a
> StateType.eStateStopped event for it. On other platforms there's no
> exception like this for the internal start breakpoint (note that actual
> breakpoints after this hit just fine)
> >
> > --
> > Carlo Kok
> > RemObjects Software
> > ___
> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Help needed regarding LLDB/MI

[Ted Woodward via lldb-dev]

Hi Rishabh,

 

It looks like you’re trying to use lldb commands when running lldb-mi. lldb-mi 
is the gdb-mi command layer on top of lldb, primarily used by tools like 
Eclipse to talk to lldb or gdb using a similar command set. These commands are 
documented here: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html 
.

 

If you’re interested in running the lldb command line debugger, don’t start MI, 
but just lldb, with “lldb”.

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of RISHABH 
GUPTA via lldb-dev
Sent: Friday, March 11, 2016 11:30 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Help needed regarding LLDB/MI

 

Hello all,

I have started using LLDB/MI but there are some commands that are not working 
.I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then launch the 
application that  I want to debug but commands like "n" ,"list","continue" 
,"step" are not working.There is this error message that gets displayed on 
giving these commands

"^error,msg="Driver. Received command 'command_name'. It was not handled. 
Command 'continue' not in Command Factory"

I tried looking for  the substitutes of these commands here 
https://github.com/llvm-mirror/lldb/tree/7535162178eada833e72a5525fc26dcc04e7331e/tools/lldb-mi
  but could not find any.

Could anyone please help me out with this?



Thank you :)

Rishabh

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

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jim Ingham via lldb-dev]

On many platforms (OS X for sure) there’s no guarantee that when you stop you 
will only have hit one breakpoint on one thread.  On OS X in multithreaded 
programs, it is not at all uncommon to have many threads hit breakpoint(s) by 
the the time the stop gets reported.  So you just have to iterate over all the 
threads and see what their stop reasons are.  Note that it isn’t just 
breakpoints, you might have been stepping on thread A, and when you stop, 
thread A will have stopped with “plan complete” for the step operation, and 
thread B for some other breakpoint.

So when you get a stop event you have to iterate over the threads and see why 
they have stopped.

LLDB will set one of the threads as the selected thread, using some heuristics 
(if you were stepping on thread A & threads A & B stopped with breakpoints, 
thread A will be the selected thread, etc…)  So you could just show the 
selected thread, but really you want to figure out what all the threads are 
doing.

Jim

> On Mar 18, 2016, at 4:25 PM, Jeffrey Tan  wrote:
> 
> 
> Hmm, interesting, I got the stop reason from the 
> lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason().
>  Is that thread not the one that stopped? But you are right, the breakpoint 
> hits in another thread:
> 
> thread #87: tid = 1006769, 0x0042eacd 
> biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x7f3ea2d74fd0,
>  corpus=error: summary string parsing error, needle=error: summary string 
> parsing error, options=0x7f3e899fc7e0) + 51 at 
> BigGrepMasterAsync.cpp:171, name = 'BigGrep-pri3-32', stop reason = 
> breakpoint 1.1
> 
> How do I know which thread hits the breakpoint?
> 
> Jeffrey
> 
> 
> On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham  > wrote:
> You only show one thread in your example.  Did another thread have a valid 
> stop reason?  lldb shouldn’t be stopping for no reason anywhere…
> 
> Jim
> 
>> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Btw: the breakpoint I set is:
>> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack 
>> frames.
>> 
>> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan > > wrote:
>> Hi,
>> 
>> Our IDE(wrapping lldb using python) works fine on Linux for simple hello 
>> world cases. While trying a real world case, I found whenever we set a 
>> source line breakpoint, then trigger the code path, lldb will send a stopped 
>> state process event, with thread.GetStopReason() being None and with weird 
>> callstack. Any ideas why do I get this stop stack(code is listed at the 
>> end)? I have verified that if I do not set breakpoint and trigger the same 
>> code path does not cause this stop event to generate.
>> 
>> bt
>> * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 
>> 51, name = 'biggrep_master_'
>>   * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
>> frame #1: 0x0271189f 
>> biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800, 
>> arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
>> frame #2: 0x0270f6d1 
>> biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800, 
>> flags=) + 225 at event.c:524
>> frame #3: 0x025f9378 
>> biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
>>  flags=0) + 834 at EventBase.cpp:335
>> frame #4: 0x025f900b 
>> biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180) 
>> + 29 at EventBase.cpp:287
>> frame #5: 0x025fa053 
>> biggrep_master_server_async`folly::EventBase::loopForever(this=0x7fd7ca945180)
>>  + 109 at EventBase.cpp:435
>> frame #6: 0x01e24b72 
>> biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x7fd7ca96d710)
>>  + 110 at ThriftServer.cpp:365
>> frame #7: 0x004906bc 
>> biggrep_master_server_async`facebook::services::ServiceFramework::startFramework(this=0x7ffc06776140,
>>  waitUntilStop=true) + 1942 at ServiceFramework.cpp:885
>> frame #8: 0x0048fe6d 
>> biggrep_master_server_async`facebook::services::ServiceFramework::go(this=0x7ffc06776140,
>>  waitUntilStop=true) + 35 at ServiceFramework.cpp:775
>> frame #9: 0x004219a7 biggrep_master_server_async`main(argc=1, 
>> argv=0x7ffc067769d8) + 2306 at BigGrepMasterServerAsync.cpp:134
>> frame #10: 0x7fd7cb1ed0f6 libc.so.6`__libc_start_main + 246
>> frame #11: 0x00420bfc biggrep_master_server_async`_start + 41 at 
>> start.S:122
>> 
>> Here is the code snippet of handling code:
>> def _handle_process_event(self, event):
>> # Ignore non-stopping events.
>> if lldb.SBProcess.GetRestartedFromEvent(event):
>> log_debug('Non stopping event: %s' % str(event))
>> return
>> 
>> process = lldb.SBProcess.GetProcessFromEvent(eve

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jim Ingham via lldb-dev]

The code that has gotten itself into an infinite loop here is the libiberty 
cp-demangle.c, which is part of the C++ runtime libraries for the system you 
are on.  So we can't do anything to fix bugs with that.  You might make sure 
there isn't a newer version of that than the one on your system, but other than 
fixing the bugs in it yourself, there's not much we can do about that one.

However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will do 
two things, it will trigger the FastDemangler that Kate wrote, and if that 
succeeds, yay!  Otherwise it will fall back to another demangler that comes 
along with the C++ standard libraries from the llvm project.  That one, like 
the cp-demangle.c is very stack intensive, but it might not have whatever bug 
you are triggering in the libiberty one.  And if it does have crashing bugs 
somebody in the clang world could fix them...

Anyway, you might try that and see if you have any more luck.  IIRC, FreeBSD 
uses the llvm one in favor of the libiberty one.

Jim


> On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> This is crazy. I tried 10MB, not working, then 20MB still not working. I got 
> around 80K frames stack overflow, this is clearly an infinitely loop in 
> "d_print_comp":
> 
> (gdb) bt
> #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586743bb0) at cp-demangle.c:4324
> #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
> #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586743ca0) at cp-demangle.c:4489
> #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
> #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586744030) at cp-demangle.c:4489
> #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, mod=) at cp-demangle.c:5539
> #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, mods=mods@entry=0x7f358534a7b0, 
> suffix=suffix@entry=0) at cp-demangle.c:5468
> #7  0x7f35925556a1 in d_print_function_type 
> (dpi=dpi@entry=0x7f3586747c00, options=options@entry=17, mods=0x7f358534a7b0, 
> dc=0x7f3586744138) at cp-demangle.c:5609
> #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
> #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586744150) at cp-demangle.c:4434
> .
> 
> #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
> #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
> #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
> #79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=dc@entry=0x7f3586744468) at cp-demangle.c:4434
> #79594 0x7f3592555f53 in d_demangle_callback (options=17, 
> opaque=0x7f3586742cc0, callback=0x7f359254b820 
> , dc=0x7f3586744468) at cp-demangle.c:4063
> #79595 0x7f3592555f53 in d_demangle_callback (mangled=,
> mangled@entry=0x0, callback=callback@entry=0x7f359254b820 
> , opaque=opaque@entry=0x7f3586747db0, 
> options=17) at cp-demangle.c:5865
> #79596 0x7f359255609f in __cxa_demangle (options=17, palc= pointer>, mangled=0x0) at cp-demangle.c:5886
> 
> #79597 0x7f359255609f in __cxa_demangle 
> (mangled_name=mangled_name@entry=0x7f3570e3d460 
> "_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect"...,
>  output_buffer=output_buffer@entry=0x0, length=length@entry=0x0, 
> status=status@entry=0x0) at cp-demangle.c:5950
> #79598 0x7f359417cc57 in 
> lldb_private::Mangled::GetDemangledName(lldb::LanguageType) const 
> (this=this@entry=0x7f3584288310, 
> language=language@entry=lldb::eLanguageTypeC_plus_plus)
> at 
> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/Mangled.cpp:316
> 
> #79599 0x7f359427adca in lldb_private::Symtab::InitNameIndexes() 
> (this=0x7f35701a8ff0) at 
> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/Symtab.cpp:334
> #79600 0x7f359427c0b8 in 
> lldb_private::Symtab::FindAllSymbolsWithNameAndType(lldb_private::ConstString 
> const&, lldb::SymbolType, std::vector int> >&) (this=this@entry=0x7f35701a8ff0, name=..., 
> symbol_type=symbol_type@entry=lldb::eSymbolTypeAny, symbol_indexes=...) at 
> /home/engshare/third-party2/lldb/3.8.

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

[Zachary Turner via lldb-dev]

Note this would also fix several longstanding warnings when compiling on
windows that there's really no other way to fix.

On Fri, Mar 18, 2016 at 10:19 AM Zachary Turner  wrote:

> Is it ok to add a public API that isn't interfaced to Python?  In this
> case the culprit is the signal() function.  Windows doesn't really support
> signal in the same way that other platforms do, so there's some code in
> each driver that basically defines a signal function, and then if you're
> unlucky when you build, or accidentally include the wrong header file (even
> indirectly), you'll get multiply defined symbol errors.
>
> So what I wanted to do was make a Host::Signal() that on Windows had our
> custom implementation, and on other platforms just called signal.  But it
> returns and accepts function pointers, and making this work through the
> python api is going to be a big deal, if not flat out impossible.
>
> The idea is that instead of writing signal() everywhere, we would write
> lldb_private::Host::Signal() everywhere instead.
>
> On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham  wrote:
>
>> The driver used to have a bunch of lldb_private stuff in it, mostly to
>> run the event loop, which Greg abstracted into SB API’s a while ago.  If it
>> can be avoided, I’d rather not add it back in.  Our claim is folks should
>> be able to write their own debugger interfaces (command line or gui) using
>> the SB API’s, so it would be good if we stuck to that discipline as well.
>>
>> I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.
>>
>> Jim
>>
>> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > I notice everything uses SB classes only.  Is this a hard requirement?
>> We have a bit of cruft in all of the top-level executables (lldb-server,
>> lldb-mi, lldb) that could be shared if we could move it into Host, but then
>> the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi
>> and lldb-server already do this, it's only lldb that doesn't.  Is this ok?
>> >
>> > If not, I can always add a method to SBHostOS and just not add a
>> corresponding swig interface definition for it (so it wouldn't be
>> accessible from Python), which would achieve basically the same effect.
>> > ___
>> > 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] Is it ok to use lldb_private from the driver?

[Greg Clayton via lldb-dev]

> On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I notice everything uses SB classes only.  Is this a hard requirement?  

I would prefer to try and get all of our tools to use the public API if at all 
possible and avoid pulling in lldb_private stuff for things like "lldb" and 
"lldb-mi". "lldb-server" isn't included in these as it is designed to not use 
the public API at all.

> We have a bit of cruft in all of the top-level executables (lldb-server, 
> lldb-mi, lldb) that could be shared if we could move it into Host, but then 
> the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi 
> and lldb-server already do this, it's only lldb that doesn't.  Is this ok?

> 
> If not, I can always add a method to SBHostOS and just not add a 
> corresponding swig interface definition for it (so it wouldn't be accessible 
> from Python), which would achieve basically the same effect.

Do you know what calls lldb-mi is cheating on? I don't believe the driver 
cheats on anything and it would be great to get "lldb-mi" to be clean as well. 
Speaking on lldb-mi, there are a bunch of places that the lldb-mi code is 
running text commands instead of using the public API. I believe 
"exec-continue" shows this quite nicely:

bool
CMICmdCmdExecContinue::Execute()
{
const char *pCmd = "continue";
CMICmnLLDBDebugSessionInfo 
&rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
const lldb::ReturnStatus rtn = 
rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd, 
m_lldbResult);


So this shows how little lldb-mi is actually using our public API. This should 
be:

bool
CMICmdCmdExecContinue::Execute()
{
CMICmnLLDBDebugSessionInfo 
&rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
SBError error = rSessionInfo.GetProcess().Continue();


So I would vote to add stuff to the public API via SBHostOS if possible. What 
kinds of things are you needing?

Let me know what you are missing so we can figure out which way to go.


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

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jim Ingham via lldb-dev]

All this logic is handled in Process::HandleProcessStateChangedEvent (see 
around line 1215 in Process.cpp)  You shouldn’t have to reimplement the logic 
for setting the selected thread unless you don’t like our heuristics.  Note, 
that’s in generic code, so I don’t know why it wouldn’t be working right on 
Linux.

Jim

> On Mar 18, 2016, at 5:38 PM, Greg Clayton  wrote:
> 
> It is really up to the IDE to decide this so the logic belongs in your IDE. 
> We do things as follows:
> 
> If no thread was selected before, display the first thread that has a stop 
> reason other than none. If no threads have stop reasons, select the first 
> thread. If a thread was selected before, then see if that same thread is 
> stopped with a reason the next time you stop and select that one, regardless 
> if it is the first thread with a stop reason. The idea is, if you were 
> stepping or doing something in a thread, and then stop again, you don't want 
> the IDE changing away from your current thread if this thread has a stop 
> reason. If this thread doesn't have a stop reason, then select the first one 
> that does. If not threads have stop reasons, then display the same thread as 
> before.
> 
>> On Mar 18, 2016, at 5:23 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Thanks for the info. I understand the multiple threads stopping at the same 
>> time issue. But I would think we should at least pick one stopped thread and 
>> set it as selected thread instead of some random thread with stop reason 
>> None. Also, in my repro case, there is only one thread that has stop reason, 
>> so the heuristics should be pretty trivial to set selected thread to that 
>> one.
>> I have workaround this issue with the suggestion but I think there is a 
>> bug(on Linux) here.
>> 
>> On Fri, Mar 18, 2016 at 4:40 PM, Jim Ingham  wrote:
>> On many platforms (OS X for sure) there’s no guarantee that when you stop 
>> you will only have hit one breakpoint on one thread.  On OS X in 
>> multithreaded programs, it is not at all uncommon to have many threads hit 
>> breakpoint(s) by the the time the stop gets reported.  So you just have to 
>> iterate over all the threads and see what their stop reasons are.  Note that 
>> it isn’t just breakpoints, you might have been stepping on thread A, and 
>> when you stop, thread A will have stopped with “plan complete” for the step 
>> operation, and thread B for some other breakpoint.
>> 
>> So when you get a stop event you have to iterate over the threads and see 
>> why they have stopped.
>> 
>> LLDB will set one of the threads as the selected thread, using some 
>> heuristics (if you were stepping on thread A & threads A & B stopped with 
>> breakpoints, thread A will be the selected thread, etc…)  So you could just 
>> show the selected thread, but really you want to figure out what all the 
>> threads are doing.
>> 
>> Jim
>> 
>>> On Mar 18, 2016, at 4:25 PM, Jeffrey Tan  wrote:
>>> 
>>> 
>>> Hmm, interesting, I got the stop reason from the 
>>> lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason().
>>>  Is that thread not the one that stopped? But you are right, the breakpoint 
>>> hits in another thread:
>>> 
>>> thread #87: tid = 1006769, 0x0042eacd 
>>> biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x7f3ea2d74fd0,
>>>  corpus=error: summary string parsing error, needle=error: summary string 
>>> parsing error, options=0x7f3e899fc7e0) + 51 at 
>>> BigGrepMasterAsync.cpp:171, name = 'BigGrep-pri3-32', stop reason = 
>>> breakpoint 1.1
>>> 
>>> How do I know which thread hits the breakpoint?
>>> 
>>> Jeffrey
>>> 
>>> 
>>> On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham  wrote:
>>> You only show one thread in your example.  Did another thread have a valid 
>>> stop reason?  lldb shouldn’t be stopping for no reason anywhere…
>>> 
>>> Jim
>>> 
 On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev 
  wrote:
 
 Btw: the breakpoint I set is:
 "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack 
 frames.
 
 On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan  
 wrote:
 Hi,
 
 Our IDE(wrapping lldb using python) works fine on Linux for simple hello 
 world cases. While trying a real world case, I found whenever we set a 
 source line breakpoint, then trigger the code path, lldb will send a 
 stopped state process event, with thread.GetStopReason() being None and 
 with weird callstack. Any ideas why do I get this stop stack(code is 
 listed at the end)? I have verified that if I do not set breakpoint and 
 trigger the same code path does not cause this stop event to generate.
 
 bt
 * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 
 51, name = 'biggrep_master_'
  * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
frame #1: 0x0271189f 
 biggrep_master_server_async`epoll_di

[lldb-dev] Is it ok to use lldb_private from the driver?

[Zachary Turner via lldb-dev]

I notice everything uses SB classes only.  Is this a hard requirement?  We
have a bit of cruft in all of the top-level executables (lldb-server,
lldb-mi, lldb) that could be shared if we could move it into Host, but then
the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi
and lldb-server already do this, it's only lldb that doesn't.  Is this ok?

If not, I can always add a method to SBHostOS and just not add a
corresponding swig interface definition for it (so it wouldn't be
accessible from Python), which would achieve basically the same effect.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Kate Stone via lldb-dev]

The cxa_demangle implementation definitely consumes stack aggressively, 
especially when compiled -O0.  I’d definitely recommend an 8MB+ stack for any 
thread that may wind up demangling arbitrary C++ symbols.  The new “fast 
demangler” is much more conservative with stack space but doesn’t yet support 
the full name mangling specification, so complex symbols often rely on falling 
back to cxa_demangle.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Mar 17, 2016, at 2:19 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Make stacks bigger when making threads on linux?
> 
>> On Mar 17, 2016, at 1:39 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Seems like the crashes happens because of abi::__cxa_demangle() for mangled 
>> symbol name " 
>> _ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect".
>> 
>> This is blocking us from releasing our C++ debugging support. Anyone know of 
>> a quick workaround I can fix it locally? Thanks!
>> 
>> On Thu, Mar 17, 2016 at 12:25 PM, via lldb-dev  
>> wrote:
>> Bug ID   26978
>> Summary  LLDB stack overflow while dealing with symbols for a process on 
>> Linux   
>> Product  lldb
>> Version  3.8
>> Hardware PC
>> OS   Linux
>> Status   NEW
>> Severity release blocker
>> Priority P
>> ComponentAll Bugs
>> Assignee lldb-dev@lists.llvm.org
>> Reporter jeffrey.fu...@gmail.com
>> CC   llvm-b...@lists.llvm.org
>> Classification   Unclassified
>> 
>> While using lldb to attach a process in our company on Linux, lldb segment
>> fault with a huge stack(more than 30K stack frames). I assume it crashes
>> because of stack overflow. Let me know what additional information you 
>> needed(I
>> have coredump):
>> 
>> #0  0x7f28ce530819 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724b80) at cp-demangle.c:4286
>> #1  0x7f28ce5321e6 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724bb0) at cp-demangle.c:4324
>> #2  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c10) at cp-demangle.c:4324
>> #3  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724c70) at cp-demangle.c:4489
>> #4  0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c88) at cp-demangle.c:4923
>> #5  0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724ca0) at cp-demangle.c:4493
>> #6  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724cd0) at cp-demangle.c:4324
>> #7  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725030) at cp-demangle.c:4489
>> #8  0x7f28ce535353 in d_print_mod (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mod=) at cp-demangle.c:5539
>> #9  0x7f28ce535dbe in d_print_mod_list (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=mods@entry=0x7f28c1f2ba30,
>> suffix=suffix@entry=0) at cp-demangle.c:5468
>> #10 0x7f28ce5366a1 in d_print_function_type 
>> (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=0x7f28c1f2ba30, dc=0x7f28c2725138) at
>> cp-demangle.c:5609
>> #11 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725138) at cp-demangle.c:4808
>> #12 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725150) at cp-demangle.c:4434
>> #13 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27251b0) at cp-demangle.c:4324
>> #14 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
>> #15 0x7f28ce534448 in d_print_comp (dpi=0x7f28c2728c00, 
>> options=> out>, dc=0x7f28c2725270) at cp-demangle.c:4793
>> #16 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725288) at cp-demangle.c:4923
>> #17 0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c27252a0) at cp-demangle.c:4493
>> #18 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27252d0) at cp-demangle.c:4324
>> #19 0x7f28ce534448 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4793
>> #20 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725330) at cp-demangle.c:4434
>> #21 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725390) at cp-demangle.c:4324
>> #22 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@en

Re: [lldb-dev] SymbolFile::FindGlobalVariables

[Greg Clayton via lldb-dev]

> On Mar 16, 2016, at 3:34 PM, Zachary Turner  wrote:
> 
> Hi Greg,
> 
> could you clarify the difference between the functions ParseTypes,

SymbolFile::ParseTypes() is only used for debugging, don't worry about this one 
unless you need a way to say "parse all types in the supplied context". It can 
help you debug things. It is only called by Module::ParseAllDebugSymbols() and 
this is only used for debugging and it isn't exposed anywhere or used by 
anyone. Just used for initial implementation. Again, see 
Module::ParseAllDebugSymbols() for all the details, but not one calls 
Module::ParseAllDebugSymbols().

> FindTypes

FindType is for finding types by name:

virtual uint32_t
FindTypes (const SymbolContext& sc, 
   const ConstString &name, 
   const CompilerDeclContext *parent_decl_ctx, 
   bool append, 
   uint32_t max_matches, 
   llvm::DenseSet &searched_symbol_files, 
   TypeMap& types);

The symbol context can limit the scope of your search if needed. Why? Because 
you might be stopped inside a "test" module that has 100 compile units, and you 
are stopped in compile unit "foo.cpp" in function "bar()". The symbol context 
can specify a scope in which to search. If a function or block is specified, 
you should find the any types in the the block, if you don't find one, proceed 
to the parent block. Keep going up the blocks, then search the class if "bar()" 
is a method, then search the compile unit for any types that match, and then 
fall back to the module. It is usually easiest to just lookup the type and come 
up with N results, and pare down the results after you find them as most times 
you will only find one type so there is no need.

If "parent_decl_ctx" is not NULL, you take all results that made it through the 
"sc" filter and then filter out any results that are not in this 
"parent_decl_ctx". The expression parser often says "I am looking for 
"basic_string" in the parent_decl_ctx that represents "namespace std".

You always check to see if "this" is in the searched_symbol_files set and only 
search if you aren't. This is for module debugging where DWARF files refer to 
types from other DWARF files.


And there is one that is specific to module debugging:

virtual size_t  FindTypes (const std::vector 
&context, bool append, TypeMap& types);

You don't need to implement this one unless you have one PDB file that refers 
to a type in another...




> ResolveTypeUID

Often types you might have a variable whose type id "typedef FooType ...;". 
Because of this, you can give your lldb_private::Variable a lldb_private::Type 
that says "I am a typedef named 'FooType' to the type with UID 0x1234. We don't 
need to resolve the type just yet and if no one needs to explore the type, we 
don't need to resolve the type right away. If anyone does ask for the 
CompilerType from a lldb_private::Type, we can then do a 
"m_symfile->ResolveTypeUID(m_encoding_uid);". So it allows us to just say "your 
type is a type from a symbol file with a user ID of 0x1234" and we can resolve 
that lazily if any only if we ever need to. Another instance where this is 
useful is when you create a lldb_private::Function:

Function (CompileUnit *comp_unit,
  lldb::user_id_t func_uid,
  lldb::user_id_t func_type_uid,
  const Mangled &mangled,
  Type * func_type,
  const AddressRange& range);

Note that you don't need to parse the function type up front, you can just make 
a function with:

SymbolFilePDB::ParseFunction(...)
{
lldb::user_id_t func_uid = 0x1234;
Mangled mangled("_Z3foo", true);
AddressRange func_range = ...;
Function *func = new Function(m_cu, func_uid, func_uid, mangled, nullptr, 
func_range);
}

Later if anyone calls:

Type* Function::GetType();

You can see if can lazily resolve its function type using ResolveTypeUID:

Type*
Function::GetType()
{
if (m_type == nullptr)
{
SymbolContext sc;

CalculateSymbolContext (&sc);

if (!sc.module_sp)
return nullptr;

SymbolVendor *sym_vendor = sc.module_sp->GetSymbolVendor();

if (sym_vendor == nullptr)
return nullptr;

SymbolFile *sym_file = sym_vendor->GetSymbolFile();

if (sym_file == nullptr)
return nullptr;

m_type = sym_file->ResolveTypeUID(m_type_uid);
}
return m_type;
}

> , and CompleteType

virtual bool SymbolFile::CompleteType (CompilerType &compiler_type);

This allows you to say "I have a class A type that is very complex and until 
someone needs to know the details about this class I will have the type 
represented as 'class A;'. Once someone needs to know the details they can 
lazily complete the type. This is very useful when creating types in 
clang::ASTContext objects because we can make a forward declaration that knows 
how to complete itself when you hook into 

Re: [lldb-dev] exception "leaks" to debugger for win32

[Greg Clayton via lldb-dev]

Ok, sounds like there is platform level precedence to support this flow and 
things should stay this way to keep Windows user experience consistent with 
other debuggers. Thanks for the info.

Greg

> On Mar 18, 2016, at 11:42 AM, Zachary Turner  wrote:
> 
> FWIW all the debuggers that people normally use on windows show it this way 
> as well.  The reason is that by default, if you do nothing and simply launch 
> a program under a debugger, you hit a breakpoint.  There's no way to avoid 
> it, it's done by the loader at the OS level.  If someone doesn't want to stop 
> at entry point (e.g. doesn't specify -s), we go out of our way to mask it.  
> So seeing that a breakpoint was hit on startup, while not consistent with 
> LLDB on other platforms, is consistent with other debuggers on Windows.  For 
> example, on WinDbg, I get this:
> 
> CommandLine: D:\infinite.exe
> Symbol search path is: *** Invalid ***
> 
> * Symbol loading may be unreliable without a symbol search path.   *
> * Use .symfix to have the debugger choose a symbol path.   *
> * After setting your symbol path, use .reload to refresh symbol locations. *
> 
> Executable search path is: 
> ModLoad: 0094 009f8000   infinite.exe
> ModLoad: 770e 7725b000   ntdll.dll
> ModLoad: 7457 7465   C:\WINDOWS\SysWOW64\KERNEL32.DLL
> ModLoad: 747a 7491e000   C:\WINDOWS\SysWOW64\KERNELBASE.dll
> ModLoad: 723e 72472000   C:\WINDOWS\SysWOW64\apphelp.dll
> ModLoad: 743e 7445b000   C:\WINDOWS\SysWOW64\ADVAPI32.dll
> ModLoad: 760b 7616e000   C:\WINDOWS\SysWOW64\msvcrt.dll
> ModLoad: 7446 744a4000   C:\WINDOWS\SysWOW64\sechost.dll
> ModLoad: 7600 760ad000   C:\WINDOWS\SysWOW64\RPCRT4.dll
> ModLoad: 73e1 73e2e000   C:\WINDOWS\SysWOW64\SspiCli.dll
> ModLoad: 73e0 73e0a000   C:\WINDOWS\SysWOW64\CRYPTBASE.dll
> ModLoad: 74a8 74ad8000   C:\WINDOWS\SysWOW64\bcryptPrimitives.dll
> (acc0.9894): Break instruction exception - code 8003 (first chance)
> *** ERROR: Symbol file could not be found.  Defaulted to export symbols for 
> ntdll.dll - 
> eax= ebx=0003 ecx=eaea edx= esi=009400f8 edi=0029e000
> eip=7718ccbc esp=0018f4e4 ebp=0018f510 iopl=0 nv up ei pl zr na pe nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=0246
> ntdll!LdrInitShimEngineDynamic+0x6dc:
> 7718ccbc cc  int 3
> 
> 
> Then you have to manually continue to skip this.  But it's still an int 3 and 
> shows up in the debugger no different than any other int 3 to the user.
> 
> On Fri, Mar 18, 2016 at 11:36 AM Greg Clayton via lldb-dev 
>  wrote:
> Anything exception that is done by the implementation in order to implement 
> normally stopping at the entry point should be covered up and not sent to the 
> user. A thread has the notion of a private stop info and one that is produced 
> for the public consumption. If this exception is indeed only showing up 
> because this is the way we were able to stop at the entry point, we should 
> not be showing that to the user.
> 
> > On Mar 18, 2016, at 11:24 AM, Carlo Kok via lldb-dev 
> >  wrote:
> >
> > When starting a process on Win32 there's an internal exception (breakpint) 
> > that leaks to the debug caller:
> > s 'Exception 0x8003 encountered at address 0x7789ccbc'#0
> >
> > This one is dealt with by the debugger internally but there's still a 
> > StateType.eStateStopped event for it. On other platforms there's no 
> > exception like this for the internal start breakpoint (note that actual 
> > breakpoints after this hit just fine)
> >
> > --
> > Carlo Kok
> > RemObjects Software
> > ___
> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26978

Bug ID: 26978
   Summary: LLDB stack overflow while dealing with symbols for a
process on Linux
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: release blocker
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jeffrey.fu...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

While using lldb to attach a process in our company on Linux, lldb segment
fault with a huge stack(more than 30K stack frames). I assume it crashes
because of stack overflow. Let me know what additional information you needed(I
have coredump):

#0  0x7f28ce530819 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2724b80) at cp-demangle.c:4286
#1  0x7f28ce5321e6 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2724bb0) at cp-demangle.c:4324
#2  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2724c10) at cp-demangle.c:4324
#3  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2724c70) at cp-demangle.c:4489
#4  0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2724c88) at cp-demangle.c:4923
#5  0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2724ca0) at cp-demangle.c:4493
#6  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2724cd0) at cp-demangle.c:4324
#7  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2725030) at cp-demangle.c:4489
#8  0x7f28ce535353 in d_print_mod (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, mod=) at cp-demangle.c:5539
#9  0x7f28ce535dbe in d_print_mod_list (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, mods=mods@entry=0x7f28c1f2ba30,
suffix=suffix@entry=0) at cp-demangle.c:5468
#10 0x7f28ce5366a1 in d_print_function_type (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, mods=0x7f28c1f2ba30, dc=0x7f28c2725138) at
cp-demangle.c:5609
#11 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725138) at cp-demangle.c:4808
#12 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2725150) at cp-demangle.c:4434
#13 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c27251b0) at cp-demangle.c:4324
#14 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
#15 0x7f28ce534448 in d_print_comp (dpi=0x7f28c2728c00, options=, dc=0x7f28c2725270) at cp-demangle.c:4793
#16 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725288) at cp-demangle.c:4923
#17 0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c27252a0) at cp-demangle.c:4493
#18 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c27252d0) at cp-demangle.c:4324
#19 0x7f28ce534448 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4793
#20 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2725330) at cp-demangle.c:4434
#21 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725390) at cp-demangle.c:4324
#22 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c27253a8) at cp-demangle.c:4742
#23 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c27253c0) at cp-demangle.c:4742
#24 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
#25 0x7f28ce53123b in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c27252e8) at cp-demangle.c:4742
#26 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725300) at cp-demangle.c:4923
#27 0x7f28ce5366e1 in d_print_function_type (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, mods=0x7f28c1f2cc70, dc=0x7f28c2725318) at
cp-demangle.c:5617
#28 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4808
#29 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
dc=0x7f28c2725330) at cp-demangle.c:4434


#31767 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
#31768 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
options=options@entry=17, dc=0x7f28c2725408) at 

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jeffrey Tan via lldb-dev]

Thanks Jim. This is very helpful.
We have double checked the libiberty we are building against which seems
already be updated two weeks ago so this bug might not been fixed yet.
Rebuilding LLDB_USE_BUILTIN_DEMANGLER fixed this stack overflow.

Questions:
1. Any reason LLDB_USE_BUILTIN_DEMANGLER is not used for other platforms?
2. Any side-effect if I use LLDB_USE_BUILTIN_DEMANGLER for lldb on other
platform?

On Thu, Mar 17, 2016 at 7:04 PM, Jim Ingham  wrote:

> The code that has gotten itself into an infinite loop here is the
> libiberty cp-demangle.c, which is part of the C++ runtime libraries for the
> system you are on.  So we can't do anything to fix bugs with that.  You
> might make sure there isn't a newer version of that than the one on your
> system, but other than fixing the bugs in it yourself, there's not much we
> can do about that one.
>
> However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will
> do two things, it will trigger the FastDemangler that Kate wrote, and if
> that succeeds, yay!  Otherwise it will fall back to another demangler that
> comes along with the C++ standard libraries from the llvm project.  That
> one, like the cp-demangle.c is very stack intensive, but it might not have
> whatever bug you are triggering in the libiberty one.  And if it does have
> crashing bugs somebody in the clang world could fix them...
>
> Anyway, you might try that and see if you have any more luck.  IIRC,
> FreeBSD uses the llvm one in favor of the libiberty one.
>
> Jim
>
>
> > On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This is crazy. I tried 10MB, not working, then 20MB still not working. I
> got around 80K frames stack overflow, this is clearly an infinitely loop in
> "d_print_comp":
> >
> > (gdb) bt
> > #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586743bb0) at cp-demangle.c:4324
> > #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
> > #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586743ca0) at cp-demangle.c:4489
> > #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
> > #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586744030) at cp-demangle.c:4489
> > #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, mod=) at cp-demangle.c:5539
> > #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, mods=mods@entry=0x7f358534a7b0,
> suffix=suffix@entry=0) at cp-demangle.c:5468
> > #7  0x7f35925556a1 in d_print_function_type 
> > (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, mods=0x7f358534a7b0, dc=0x7f3586744138) at
> cp-demangle.c:5609
> > #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
> > #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17,
> dc=0x7f3586744150) at cp-demangle.c:4434
> > .
> >
> > #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
> > #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
> > #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
> > #79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
> options=options@entry=17, dc=dc@entry=0x7f3586744468) at
> cp-demangle.c:4434
> > #79594 0x7f3592555f53 in d_demangle_callback (options=17,
> opaque=0x7f3586742cc0, callback=0x7f359254b820
> , dc=0x7f3586744468) at
> cp-demangle.c:4063
> > #79595 0x7f3592555f53 in d_demangle_callback (mangled= out>,
> > mangled@entry=0x0, callback=callback@entry=0x7f359254b820
> , opaque=opaque@entry=0x7f3586747db0,
> options=17) at cp-demangle.c:5865
> > #79596 0x7f359255609f in __cxa_demangle (options=17, palc= pointer>, mangled=0x0) at cp-demangle.c:5886
> >
> > #79597 0x7f359255609f in __cxa_demangle
> (mangled_name=mangled_name@entry=0x7f3570e3d460
> "_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect"...,
> output_buffer=output_buffer@entry=0x0, length=length@entry=0x0,
> status=status@entry=0x0) at cp-demangle.c:5950
> > #79598 0x7f359417cc57 in
> lldb_private::Mangled::GetDemangledName(lldb::LanguageType) const
> (this=this@entry=0x7f3584288310, language=language@entry
> =lldb::eLanguageTypeC_plus_plus)
> > at
> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/too

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Kate Stone via lldb-dev]

Not all platforms use the same C++ name mangling.  Clang follows the Itanium 
ABI specification which is what both the built-in LLDB demanglers understand.

Kate Stone k8st...@apple.com
 Xcode Low Level Tools

> On Mar 18, 2016, at 3:50 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Thanks Jim. This is very helpful. 
> We have double checked the libiberty we are building against which seems 
> already be updated two weeks ago so this bug might not been fixed yet. 
> Rebuilding LLDB_USE_BUILTIN_DEMANGLER fixed this stack overflow. 
> 
> Questions:
> 1. Any reason LLDB_USE_BUILTIN_DEMANGLER is not used for other platforms? 
> 2. Any side-effect if I use LLDB_USE_BUILTIN_DEMANGLER for lldb on other 
> platform?
> 
>> On Thu, Mar 17, 2016 at 7:04 PM, Jim Ingham  wrote:
>> The code that has gotten itself into an infinite loop here is the libiberty 
>> cp-demangle.c, which is part of the C++ runtime libraries for the system you 
>> are on.  So we can't do anything to fix bugs with that.  You might make sure 
>> there isn't a newer version of that than the one on your system, but other 
>> than fixing the bugs in it yourself, there's not much we can do about that 
>> one.
>> 
>> However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will 
>> do two things, it will trigger the FastDemangler that Kate wrote, and if 
>> that succeeds, yay!  Otherwise it will fall back to another demangler that 
>> comes along with the C++ standard libraries from the llvm project.  That 
>> one, like the cp-demangle.c is very stack intensive, but it might not have 
>> whatever bug you are triggering in the libiberty one.  And if it does have 
>> crashing bugs somebody in the clang world could fix them...
>> 
>> Anyway, you might try that and see if you have any more luck.  IIRC, FreeBSD 
>> uses the llvm one in favor of the libiberty one.
>> 
>> Jim
>> 
>> 
>> > On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev 
>> >  wrote:
>> >
>> > This is crazy. I tried 10MB, not working, then 20MB still not working. I 
>> > got around 80K frames stack overflow, this is clearly an infinitely loop 
>> > in "d_print_comp":
>> >
>> > (gdb) bt
>> > #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586743bb0) at cp-demangle.c:4324
>> > #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
>> > #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586743ca0) at cp-demangle.c:4489
>> > #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
>> > #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586744030) at cp-demangle.c:4489
>> > #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, mod=) at cp-demangle.c:5539
>> > #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, mods=mods@entry=0x7f358534a7b0, 
>> > suffix=suffix@entry=0) at cp-demangle.c:5468
>> > #7  0x7f35925556a1 in d_print_function_type 
>> > (dpi=dpi@entry=0x7f3586747c00, options=options@entry=17, 
>> > mods=0x7f358534a7b0, dc=0x7f3586744138) at cp-demangle.c:5609
>> > #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
>> > #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586744150) at cp-demangle.c:4434
>> > .
>> >
>> > #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
>> > #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
>> > #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
>> > #79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=dc@entry=0x7f3586744468) at cp-demangle.c:4434
>> > #79594 0x7f3592555f53 in d_demangle_callback (options=17, 
>> > opaque=0x7f3586742cc0, callback=0x7f359254b820 
>> > , dc=0x7f3586744468) at 
>> > cp-demangle.c:4063
>> > #79595 0x7f3592555f53 in d_demangle_callback (mangled=,
>> > mangled@entry=0x0, callback=callback@entry=0x7f359254b820 
>> > , opaque=opaque@entry=0x7f3586747db0, 
>> > options=17) at cp-demangle.c:5865
>> > #79596 0x7f359255609f in __cxa_demangle (options=17, palc=> > pointer>, mangled=0x0) at cp-demangle.c:5886
>> >
>> > #79597 0x7f359255609f in __cxa_demangle 
>> > (mangled_name=mangled_name@entry=0x7f3570e3d460 
>> > "_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

[Greg Clayton via lldb-dev]

> On Mar 18, 2016, at 10:20 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Is it ok to add a public API that isn't interfaced to Python?  In this case 
> the culprit is the signal() function.  Windows doesn't really support signal 
> in the same way that other platforms do, so there's some code in each driver 
> that basically defines a signal function, and then if you're unlucky when you 
> build, or accidentally include the wrong header file (even indirectly), 
> you'll get multiply defined symbol errors.
> 
> So what I wanted to do was make a Host::Signal() that on Windows had our 
> custom implementation, and on other platforms just called signal.  But it 
> returns and accepts function pointers, and making this work through the 
> python api is going to be a big deal, if not flat out impossible.

Why is this an issue in Python? Doesn't python abstract this for you? Or is it 
just a NOP on windows??
> 
> The idea is that instead of writing signal() everywhere, we would write 
> lldb_private::Host::Signal() everywhere instead.  

Is this just to get a callback when a certain signal is sent to a process, like 
to handle SIGINT?

Why this is hard to hook through SBHostOS if python doesn't provide an 
abstraction?

> 
> On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham  wrote:
> The driver used to have a bunch of lldb_private stuff in it, mostly to run 
> the event loop, which Greg abstracted into SB API’s a while ago.  If it can 
> be avoided, I’d rather not add it back in.  Our claim is folks should be able 
> to write their own debugger interfaces (command line or gui) using the SB 
> API’s, so it would be good if we stuck to that discipline as well.
> 
> I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.
> 
> Jim
> 
> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > I notice everything uses SB classes only.  Is this a hard requirement?  We 
> > have a bit of cruft in all of the top-level executables (lldb-server, 
> > lldb-mi, lldb) that could be shared if we could move it into Host, but then 
> > the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi 
> > and lldb-server already do this, it's only lldb that doesn't.  Is this ok?
> >
> > If not, I can always add a method to SBHostOS and just not add a 
> > corresponding swig interface definition for it (so it wouldn't be 
> > accessible from Python), which would achieve basically the same effect.
> > ___
> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Greg Clayton via lldb-dev]

So you will need to find out who is sliding the shared library incorrectly. It 
might be a packet that is received through the GDB remote protocol, so there 
might be a bug in your GDB server.

Greg

> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
> wrote:
> 
> Your guess is right - the sections moved. Before attaching:
> 
>  0x0008 code [0x0003-0x00068d5c)  
> 0x00011000 0x00038d5c 0x0006 dlopen..text
> 
> After attaching:
> 
>  0x0008 code [0x0001-0x00048d5c)  
> 0x00011000 0x00038d5c 0x0006 dlopen..text
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Thursday, March 17, 2016 12:44 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
> correctly
> 
> Sounds like something is going wrong when resolving the address. I am 
> guessing that your sections got unloaded when you attached to your GDB remote 
> target. So try this:
> 
> (lldb) file u:\lldb_test\dlopen
> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
> (lldb) target modules load -f dlopen -s 0x2
> (lldb) b main
> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018
> 
> Note we got the address correct. Now do a:
> 
> (lldb) image dump sections dlopen
> 
> Check to make sure all addresses for the sections look good.
> 
> Now do:
> 
> (lldb) gdb-remote tedwood-ubuntu:5556
> (lldb) image dump sections dlopen
> 
> I am guessing that the sections have been moved...
> 
> Let me know what you find.
> 
>> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> I’m seeing 2 issues with “target modules load”:
>> 
>> 
>> 
>> Issue #1: load address is forgotten after a connect:
>> 
>> (lldb) file u:\lldb_test\dlopen
>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>> (lldb) target modules load -f dlopen -s 0x2
>> (lldb) b main
>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 
>> 0x00030018
>> (lldb) gdb-remote tedwood-ubuntu:5556
>> 
>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address = 
>> 0x10018 <  14> send packet: $Z0,10018,4#10
>> <   4> read packet: $#00
>> Software breakpoints are unsupported
>> <  14> send packet: $Z1,10018,4#11
>> <   6> read packet: $OK#9a
>> 
>> (lldb) br l
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>> resolved, hit count = 0
>> 
>> 
>> 
>> 
>> Issue #2: breakpoints on the remote server aren’t updated with a new load 
>> address, even though they’re updated in the breakpoint list:
>> 
>> (lldb) br l
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>> resolved, hit count = 0
>> 
>> (lldb) target modules load -f dlopen -s 0x2
>> (lldb) br l
>> <   7> send packet: $p29#db
>> <  12> read packet: $0010#81
>> <   7> send packet: $p1d#05
>> <  12> read packet: $#80
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
>> resolved, hit count = 0
>> 
>> (lldb) c
>> Process 1 stopped
>> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1, 
>> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1
>>frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at 
>> dlopen.c:26
>> 
>> (lldb) re r pc
>>  pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>> 
>> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 
>> 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a Z 
>> packet to add one at 0x30018.
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
>> a Linux Foundation Collaborative Project
>> 
>> ___
>> 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] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

I don't see anything in the packet log that would cause the change. Most of the 
interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) return an 
empty reply.

Where should I set a breakpoint to see the load addresses moving?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Friday, March 18, 2016 3:12 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
correctly

So you will need to find out who is sliding the shared library incorrectly. It 
might be a packet that is received through the GDB remote protocol, so there 
might be a bug in your GDB server.

Greg

> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
> wrote:
> 
> Your guess is right - the sections moved. Before attaching:
> 
>  0x0008 code [0x0003-0x00068d5c)  
> 0x00011000 0x00038d5c 0x0006 dlopen..text
> 
> After attaching:
> 
>  0x0008 code [0x0001-0x00048d5c)  
> 0x00011000 0x00038d5c 0x0006 dlopen..text
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Thursday, March 17, 2016 12:44 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
> working correctly
> 
> Sounds like something is going wrong when resolving the address. I am 
> guessing that your sections got unloaded when you attached to your GDB remote 
> target. So try this:
> 
> (lldb) file u:\lldb_test\dlopen
> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
> (lldb) target modules load -f dlopen -s 0x2
> (lldb) b main
> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 
> 0x00030018
> 
> Note we got the address correct. Now do a:
> 
> (lldb) image dump sections dlopen
> 
> Check to make sure all addresses for the sections look good.
> 
> Now do:
> 
> (lldb) gdb-remote tedwood-ubuntu:5556
> (lldb) image dump sections dlopen
> 
> I am guessing that the sections have been moved...
> 
> Let me know what you find.
> 
>> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> I’m seeing 2 issues with “target modules load”:
>> 
>> 
>> 
>> Issue #1: load address is forgotten after a connect:
>> 
>> (lldb) file u:\lldb_test\dlopen
>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>> (lldb) target modules load -f dlopen -s 0x2
>> (lldb) b main
>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
>> 0x00030018
>> (lldb) gdb-remote tedwood-ubuntu:5556
>> 
>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address =
>> 0x10018 <  14> send packet: $Z0,10018,4#10
>> <   4> read packet: $#00
>> Software breakpoints are unsupported
>> <  14> send packet: $Z1,10018,4#11
>> <   6> read packet: $OK#9a
>> 
>> (lldb) br l
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>> resolved, hit count = 0
>> 
>> 
>> 
>> 
>> Issue #2: breakpoints on the remote server aren’t updated with a new load 
>> address, even though they’re updated in the breakpoint list:
>> 
>> (lldb) br l
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>> resolved, hit count = 0
>> 
>> (lldb) target modules load -f dlopen -s 0x2
>> (lldb) br l
>> <   7> send packet: $p29#db
>> <  12> read packet: $0010#81
>> <   7> send packet: $p1d#05
>> <  12> read packet: $#80
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
>> resolved, hit count = 0
>> 
>> (lldb) c
>> Process 1 stopped
>> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1,
>> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1
>>frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at
>> dlopen.c:26
>> 
>> (lldb) re r pc
>>  pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>> 
>> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 
>> 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a Z 
>> packet to add one at 0x30018.
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>> Forum, a Linux Foundation Collaborative Project
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

[Zachary Turner via lldb-dev]

Is it ok to add a public API that isn't interfaced to Python?  In this case
the culprit is the signal() function.  Windows doesn't really support
signal in the same way that other platforms do, so there's some code in
each driver that basically defines a signal function, and then if you're
unlucky when you build, or accidentally include the wrong header file (even
indirectly), you'll get multiply defined symbol errors.

So what I wanted to do was make a Host::Signal() that on Windows had our
custom implementation, and on other platforms just called signal.  But it
returns and accepts function pointers, and making this work through the
python api is going to be a big deal, if not flat out impossible.

The idea is that instead of writing signal() everywhere, we would write
lldb_private::Host::Signal() everywhere instead.

On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham  wrote:

> The driver used to have a bunch of lldb_private stuff in it, mostly to run
> the event loop, which Greg abstracted into SB API’s a while ago.  If it can
> be avoided, I’d rather not add it back in.  Our claim is folks should be
> able to write their own debugger interfaces (command line or gui) using the
> SB API’s, so it would be good if we stuck to that discipline as well.
>
> I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.
>
> Jim
>
> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I notice everything uses SB classes only.  Is this a hard requirement?
> We have a bit of cruft in all of the top-level executables (lldb-server,
> lldb-mi, lldb) that could be shared if we could move it into Host, but then
> the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi
> and lldb-server already do this, it's only lldb that doesn't.  Is this ok?
> >
> > If not, I can always add a method to SBHostOS and just not add a
> corresponding swig interface definition for it (so it wouldn't be
> accessible from Python), which would achieve basically the same effect.
> > ___
> > 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] SymbolFile::FindGlobalVariables

[Zachary Turner via lldb-dev]

Hi Greg,

could you clarify the difference between the functions ParseTypes,
FindTypes, ResolveTypeUID, and CompleteType from the SymbolFile plugin?

On Mon, Mar 14, 2016 at 1:33 PM Zachary Turner  wrote:

> Bleh, it looks like some abstraction will be needed at this level too,
> because ClangASTContext assumes a DWARFASTParser.
>
> This doesn't seem too bad, because the only code that actually assumes
> it's a DWARFASTParser is in SymbolFileDWARF.  So maybe creating a
> DebugInfoASTParser in lldb/Symbol and then making a PDBASTParser would be
> enough to get this working.
>
> Seem reasonable?
>
> On Mon, Mar 14, 2016 at 8:14 AM Zachary Turner  wrote:
>
>> It looks like i need to get type information working before variables, so
>> I'll work on that first and come back to this
>> On Fri, Mar 11, 2016 at 5:05 PM Greg Clayton  wrote:
>>
>>>
>>> > On Mar 11, 2016, at 1:02 PM, Zachary Turner 
>>> wrote:
>>> >
>>> > How large of a change do you think it would be to abstract out the
>>> location information for the variable?  As far as I can tell, our uses of
>>> this DWARFExpression on Variables are very limited:
>>> >
>>> > 1. In ValueObjectVariable::UpdateValue and
>>> ClangExpressionDeclMap::GetVariableValue, if the location is a constant
>>> value, it refers to a a host address, we just read the value out as a
>>> number.
>>> > 2. In EntityVariable::Materialize(), we check whether it is valid.
>>> > 3. In SymbolFileDWARF, we "evaluate" the expression.
>>>
>>> Leave this one alone, don't abstract it since it is DWARF native.
>>>
>>> > 4. In a few places, we check whether an input address matches the
>>> location specified.
>>> > 5. We dump the location to stdout in a few places.
>>> >
>>> > Everything else could just as easily be private methods, because
>>> that's all that public users of DWARFExpression actually use.
>>>
>>> Sounds like it won't be too bad.
>>> >
>>> > This seems like an easy abstraction to create.  #3 is irrelevant
>>> because that code is in SymbolFileDWARF, it could downcast from Location to
>>> DWARFLocation.  #1, 2, 4, and 5 could easily be implemented directly
>>> against a PDB.
>>> >
>>> > While I haven't tried to actually *do* either approach yet, I like the
>>> idea of creating the abstraction because it provides the native / most
>>> optimized debugging experience no matter what you're using.  For example, I
>>> can easily imagine a scenario where I have to keep the PDB open in memory
>>> to query some types of information, but I have to do a conversion of
>>> location information for Variables, and the memory usage becomes
>>> unacceptable because everything is memory twice (even though it's lazily
>>> evaluated, the memory usage would double over time).
>>>
>>> You will abstract the location only and that is fine. For everything
>>> else we do have lldb classes that will need to be created (compile units,
>>> functions, blocks, variables). Types are done via the TypeSystem subclasses
>>> so you will need convert all types there. So feel free to abstract the
>>> DWARFExpression for variable locations only.
>>>
>>> I have no problem with the abstraction if you think it is needed. I
>>> personally think it will be much more work, but I won't be doing it so I
>>> don't mind.
>>>
>>> Greg
>>>
>>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Help needed regarding LLDB/MI

[RISHABH GUPTA via lldb-dev]

On Wed, Mar 16, 2016 at 10:41 PM, Greg Clayton  wrote:

>
> > On Mar 11, 2016, at 9:30 AM, RISHABH GUPTA via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello all,
> >
> > I have started using LLDB/MI but there are some commands that are not
> working .I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then
> launch the application that  I want to debug but commands like "n"
> ,"list","continue" ,"step" are not working.There is this error message that
> gets displayed on giving these commands
> >
> > "^error,msg="Driver. Received command 'command_name'. It was not
> handled. Command 'continue' not in Command Factory"
>
> Was this something you were typing at a "(gdb)" prompt?


Yes


> If not, it sounds like your software is using GDB commands instead of
> using the actual MI commands and the best solutions is to fix your software
> to actually use the MI commands instead of sending GDB command interpreter
> commands.
>
> I believe there is some way to send a gdb command line command, so if you
> have a "(gdb) " prompt, and we will pass the command along to LLDB.
> >
> > I tried looking for  the substitutes of these commands here
> https://github.com/llvm-mirror/lldb/tree/7535162178eada833e72a5525fc26dcc04e7331e/tools/lldb-mi
> but could not find any.
> >
> > Could anyone please help me out with this?
>
> So check if your IDE is not actually using MI. Your IDE shouldn't send a
> "continue" GDB command interpreter command, but it should send an
> "exec-continue" MI packet since you are using MI. Don't sent a "n" packet,
> but send a "exec-next" packet. Etc...
>
>
till now I have been using the MI in the terminal itself .I figured out the
corresponding MI commands for 'n','step','continue' but not for 'list'.

The thing is GDB/MI commands listed here
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html#GDB_002fMI  don't
just work outside the box when used with LLDB/MI .for example:

1.In GDB/MI -exec-next commands works fine but to make it work for LLDB/MI
we need to provide the thread number ,so the command becomes "-exec-next
--thread 1"

2.-var-update command ,In GDB/MI "-var-update *" works fine  but the same
command in LLDB/MI gives
"^error,msg="Command 'var-update'. Variable '*' does not exist"

So it takes time to figure out the correct usage of the command


Let me know what your IDE is doing.
>

They are implementing the MI only

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

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Greg Clayton via lldb-dev]

SectionLoadList::SetSectionLoadAddress() in SectionLoadList.cpp

> On Mar 18, 2016, at 1:54 PM, Ted Woodward  wrote:
> 
> I don't see anything in the packet log that would cause the change. Most of 
> the interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) 
> return an empty reply.
> 
> Where should I set a breakpoint to see the load addresses moving?
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Friday, March 18, 2016 3:12 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
> correctly
> 
> So you will need to find out who is sliding the shared library incorrectly. 
> It might be a packet that is received through the GDB remote protocol, so 
> there might be a bug in your GDB server.
> 
> Greg
> 
>> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
>> wrote:
>> 
>> Your guess is right - the sections moved. Before attaching:
>> 
>> 0x0008 code [0x0003-0x00068d5c)  
>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>> 
>> After attaching:
>> 
>> 0x0008 code [0x0001-0x00048d5c)  
>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
>> a Linux Foundation Collaborative Project
>> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Thursday, March 17, 2016 12:44 PM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
>> working correctly
>> 
>> Sounds like something is going wrong when resolving the address. I am 
>> guessing that your sections got unloaded when you attached to your GDB 
>> remote target. So try this:
>> 
>> (lldb) file u:\lldb_test\dlopen
>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>> (lldb) target modules load -f dlopen -s 0x2
>> (lldb) b main
>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 
>> 0x00030018
>> 
>> Note we got the address correct. Now do a:
>> 
>> (lldb) image dump sections dlopen
>> 
>> Check to make sure all addresses for the sections look good.
>> 
>> Now do:
>> 
>> (lldb) gdb-remote tedwood-ubuntu:5556
>> (lldb) image dump sections dlopen
>> 
>> I am guessing that the sections have been moved...
>> 
>> Let me know what you find.
>> 
>>> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev 
>>>  wrote:
>>> 
>>> I’m seeing 2 issues with “target modules load”:
>>> 
>>> 
>>> 
>>> Issue #1: load address is forgotten after a connect:
>>> 
>>> (lldb) file u:\lldb_test\dlopen
>>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>>> (lldb) target modules load -f dlopen -s 0x2
>>> (lldb) b main
>>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
>>> 0x00030018
>>> (lldb) gdb-remote tedwood-ubuntu:5556
>>> 
>>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address =
>>> 0x10018 <  14> send packet: $Z0,10018,4#10
>>> <   4> read packet: $#00
>>> Software breakpoints are unsupported
>>> <  14> send packet: $Z1,10018,4#11
>>> <   6> read packet: $OK#9a
>>> 
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>>> resolved, hit count = 0
>>> 
>>> 
>>> 
>>> 
>>> Issue #2: breakpoints on the remote server aren’t updated with a new load 
>>> address, even though they’re updated in the breakpoint list:
>>> 
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>>> resolved, hit count = 0
>>> 
>>> (lldb) target modules load -f dlopen -s 0x2
>>> (lldb) br l
>>> <   7> send packet: $p29#db
>>> <  12> read packet: $0010#81
>>> <   7> send packet: $p1d#05
>>> <  12> read packet: $#80
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
>>> resolved, hit count = 0
>>> 
>>> (lldb) c
>>> Process 1 stopped
>>> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1,
>>> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1
>>>   frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at
>>> dlopen.c:26
>>> 
>>> (lldb) re r pc
>>> pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>>> 
>>> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 
>>> 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a 
>>> Z packet to add one at 0x30018.
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jeffrey Tan via lldb-dev]

This is crazy. I tried 10MB, not working, then 20MB still not working. I
got around 80K frames stack overflow, this is clearly an infinitely loop in
"d_print_comp":

(gdb) bt
#0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17,
dc=0x7f3586743bb0) at cp-demangle.c:4324
#1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
#2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17,
dc=0x7f3586743ca0) at cp-demangle.c:4489
#3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
#4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17,
dc=0x7f3586744030) at cp-demangle.c:4489
#5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, mod=) at cp-demangle.c:5539
#6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, mods=mods@entry=0x7f358534a7b0,
suffix=suffix@entry=0) at cp-demangle.c:5468
#7  0x7f35925556a1 in d_print_function_type (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, mods=0x7f358534a7b0, dc=0x7f3586744138) at
cp-demangle.c:5609
#8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
#9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17,
dc=0x7f3586744150) at cp-demangle.c:4434
.

#79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
#79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
#79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
#79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00,
options=options@entry=17, dc=dc@entry=0x7f3586744468) at cp-demangle.c:4434
#79594 0x7f3592555f53 in d_demangle_callback (options=17,
opaque=0x7f3586742cc0, callback=0x7f359254b820
, dc=0x7f3586744468) at
cp-demangle.c:4063
#79595 0x7f3592555f53 in d_demangle_callback (mangled=,
mangled@entry=0x0, callback=callback@entry=0x7f359254b820
, opaque=opaque@entry=0x7f3586747db0,
options=17) at cp-demangle.c:5865
#79596 0x7f359255609f in __cxa_demangle (options=17, palc=, mangled=0x0) at cp-demangle.c:5886

*#79597 0x7f359255609f in __cxa_demangle
(mangled_name=mangled_name@entry=0x7f3570e3d460
"_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect"...,
output_buffer=output_buffer@entry=0x0, length=length@entry=0x0,
status=status@entry=0x0) at cp-demangle.c:5950*
#79598 0x7f359417cc57 in
lldb_private::Mangled::GetDemangledName(lldb::LanguageType) const
(this=this@entry=0x7f3584288310, language=language@entry
=lldb::eLanguageTypeC_plus_plus)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/Mangled.cpp:316

#79599 0x7f359427adca in lldb_private::Symtab::InitNameIndexes()
(this=0x7f35701a8ff0) at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/Symtab.cpp:334
#79600 0x7f359427c0b8 in
lldb_private::Symtab::FindAllSymbolsWithNameAndType(lldb_private::ConstString
const&, lldb::SymbolType, std::vector >&) (this=this@entry=0x7f35701a8ff0, name=...,
symbol_type=symbol_type@entry=lldb::eSymbolTypeAny, symbol_indexes=...) at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/Symtab.cpp:819

#79601 0x7f359417fec2 in
lldb_private::Module::FindSymbolsWithNameAndType(lldb_private::ConstString
const&, lldb::SymbolType, lldb_private::SymbolContextList&)
(this=0x7f35700605a0, name=...,
symbol_type=symbol_type@entry=lldb::eSymbolTypeAny,
sc_list=...) at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/Module.cpp:1432
#79602 0x7f359418681d in
lldb_private::ModuleList::FindSymbolsWithNameAndType(lldb_private::ConstString
const&, lldb::SymbolType, lldb_private::SymbolContextList&, bool) const
(this=this@entry=0x7f35867484b0, name=...,
symbol_type=symbol_type@entry=lldb::eSymbolTypeAny,
sc_list=..., append=append@entry=false) at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ModuleList.cpp:573
#79603 0x7f3594533626 in
JITLoaderGDB::GetSymbolAddress(lldb_private::ModuleList&,
lldb_private::ConstString const&, lldb::SymbolType) const
(this=this@entry=0x7f3570042990,
module_list=..., name=..., symbol_type=symbol_type@entry=lldb::eSymbolTypeAny)
at
/home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp:500



#79604 0x7f35945354cb in
JITLoaderGDB::SetJITBreakpoint(lldb_private::ModuleList&)

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

Your guess is right - the sections moved. Before attaching:

  0x0008 code [0x0003-0x00068d5c)  
0x00011000 0x00038d5c 0x0006 dlopen..text

After attaching:

  0x0008 code [0x0001-0x00048d5c)  
0x00011000 0x00038d5c 0x0006 dlopen..text

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Thursday, March 17, 2016 12:44 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
correctly

Sounds like something is going wrong when resolving the address. I am guessing 
that your sections got unloaded when you attached to your GDB remote target. So 
try this:

(lldb) file u:\lldb_test\dlopen
Current executable set to 'u:\lldb_test\dlopen' (hexagon).
(lldb) target modules load -f dlopen -s 0x2
(lldb) b main
Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018

Note we got the address correct. Now do a:

(lldb) image dump sections dlopen

Check to make sure all addresses for the sections look good.

Now do:

(lldb) gdb-remote tedwood-ubuntu:5556
(lldb) image dump sections dlopen

I am guessing that the sections have been moved...

Let me know what you find.

> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I’m seeing 2 issues with “target modules load”:
>  
>  
>  
> Issue #1: load address is forgotten after a connect:
>  
> (lldb) file u:\lldb_test\dlopen
> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
> (lldb) target modules load -f dlopen -s 0x2
> (lldb) b main
> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 
> 0x00030018
> (lldb) gdb-remote tedwood-ubuntu:5556
>  
> But it’s set the breakpoint at 0x10018 instead of 0x30018:
> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address = 
> 0x10018 <  14> send packet: $Z0,10018,4#10
> <   4> read packet: $#00
> Software breakpoints are unsupported
> <  14> send packet: $Z1,10018,4#11
> <   6> read packet: $OK#9a
>  
> (lldb) br l
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
> resolved, hit count = 0
>  
>  
>  
>  
> Issue #2: breakpoints on the remote server aren’t updated with a new load 
> address, even though they’re updated in the breakpoint list:
>  
> (lldb) br l
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
> resolved, hit count = 0
>  
> (lldb) target modules load -f dlopen -s 0x2
> (lldb) br l
> <   7> send packet: $p29#db
> <  12> read packet: $0010#81
> <   7> send packet: $p1d#05
> <  12> read packet: $#80
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
> resolved, hit count = 0
>  
> (lldb) c
> Process 1 stopped
> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1, 
> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1
> frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at 
> dlopen.c:26
>  
> (lldb) re r pc
>   pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>  
> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 
> 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a Z 
> packet to add one at 0x30018.
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>  
> ___
> 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] exception "leaks" to debugger for win32

[Carlo Kok via lldb-dev]

ah yes! Disabling that fixed it. Thanks

Op 2016-03-18 om 19:29 schreef Zachary Turner:

Are you launching the process with -s (stop at entry)?

On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:

When starting a process on Win32 there's an internal exception
(breakpint) that leaks to the debug caller:
s   'Exception 0x8003 encountered at address 0x7789ccbc'#0

This one is dealt with by the debugger internally but there's still a
StateType.eStateStopped event for it. On other platforms there's no
exception like this for the internal start breakpoint (note that actual
breakpoints after this hit just fine)

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



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