[lldb-dev] Linux issues where I am not getting breakpoints...

Wed Apr 12 10:19:07 PDT 2017

BTW, lldb has a setting:

settings set target.process.extra-startup-command

In the Process GDBRemote case if this is set lldb sends whatever packet you specify to the stub before starting the normal sequence. 

We added support in debugserver for a QSetLogging packet, which we use like:

QSetLogging:bitmask=LOG_TASK;

That turns on debugserver's LOG_TASK log channel.  That has been very handy over time, particularly lldb is running under some other process (e.g. Xcode) and adjusting environment variables isn't so easy.  That or something similar might be good to support in lldb-server as well.

Jim

> On Apr 12, 2017, at 10:05 AM, Tamas Berghammer via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> If the process is restarted by lldb-server then "posix ptrace" should have some indication about it. Also "posix process" and "posix thread" can be useful to understand the bigger picture (all of them in lldb-server).
> 
> Note: You can enable them by setting LLDB_SERVER_LOG_CHANNELS and LLDB_DEBUGSERVER_LOG_FILE environment variables before starting lldb.
> 
> On Wed, Apr 12, 2017 at 5:11 PM Greg Clayton <clayborg at gmail.com> wrote:
> What is actually happening is we are stopped and handling the EntryBreakpoint and are in the process of trying to load all shared libraries, and then a signal (I am guessing) comes into the lldb-server and causes the target to resume. Not sure if that is due to the signal passing packet:
> 
> $QPassSignals:0e;1b;20;21;22;23;24;25;26;27;28;29;2a;2b;2c;2d;2e;2f;30;31;32;33;34;35;36;37;38;39;3a;3b;3c;3d;3e;3f;40#69
> 
> that gets sent these days. I will try removing this and seeing if it fixes anything.
> 
> Is there any logging I can enabled in lldb-server to catch the resume? I haven't looked at the code but I finally proved what was happening last night (target resumes while we are stopped at a breakpoint somehow). The program runs and exits and when the shared libraries are finally done loading, there is no connection to speak to.
> 
> Greg
> 
>> On Apr 11, 2017, at 8:26 AM, Pavel Labath <labath at google.com> wrote:
>> 
>> 
>> 
>> On 11 April 2017 at 15:56, Greg Clayton <clayborg at gmail.com> wrote:
>> 
>>> On Apr 11, 2017, at 5:33 AM, Pavel Labath <labath at google.com> wrote:
>>> 
>>> Are you sure this is not just an artifact of stdio buffering? I tried the same experiment, but I placed a real log statement, and I could see that all the LoadModuleAtAddress calls happen between the $T and $c packets in the gdb-remote packet sequence. 
>>> 
>>> The module loading should be synchronous, so I think the problem lies elsewhere.
>>> 
>>> What is the nature of the breakpoint that is not getting hit? Can you provide a repro case? The only bug like this that I am aware of is that we fail to hit breakpoints in global constructors in shared libraries, but that hasn't worked even in 3.8..
>> 
>> I unfortunately can't attach a repro case. I will be able to track this down, just need some pointers. I did notice that I wasn't able to hit breakpoints in global constructors though... Do we know why? On Mac, we get notified of shared libraries as they load so we never miss anything. Why are we not able to get the same thing with linux?
>> 
>> 
>> It looks like we are intercepting the library load too late, but I haven't investigated yet how to fix it. It's definitely possible (this works fine in gdb), but I don't know how, as the dynamic linker is still a big unknown to me. FWIW, I think I'll be messing with the dynamic loader plugin soon(ish), so I'll try to fix this then.
>> 
>> pl
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev