What I now believe is happening is lldb-server is exiting for some reason and
then the process just runs and still shows the output in LLDB because we hooked
up the STDIO. I see lldb-server exits with an exit code of 0, but no command
had been sent to terminate it. I will track that down.
Also, log_channels in lldb-gdbserver.cpp is using a llvm::StringRef incorrectly:
case 'c': // Log Channels
if (optarg && optarg[0])
log_channels = StringRef(optarg);
break;
Bad! This is exactly when we shouldn't be using llvm::StringRef. optarg is a
static variable and can change if there are any arguments after "-c <args>".
Greg
> On Apr 12, 2017, at 10:05 AM, Tamas Berghammer <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> On 11 April 2017 at 15:56, Greg Clayton <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On Apr 11, 2017, at 5:33 AM, Pavel Labath <[email protected]
>>> <mailto:[email protected]>> 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
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
