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 <lab...@google.com> wrote: > > > > On 11 April 2017 at 15:56, Greg Clayton <clayb...@gmail.com > <mailto:clayb...@gmail.com>> wrote: > >> On Apr 11, 2017, at 5:33 AM, Pavel Labath <lab...@google.com >> <mailto:lab...@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@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
