<div dir="ltr">I seem to recall on the Linux side that this gets a bit complicated.  Attaching vs. launching get different sequences of stops, as do the number of hops through possible shells in between a launch and an attach.  So we pass through a skip-stop count (which I think both OS X and Linux use) to figure out how many of them we need to skip before we say we're attached.<div><br></div><div>Are we at the point where everything is using lldb-server/debugserver everywhere on OS X/Linux/*BSD even for local debugging?  If so, all those platforms probably have a point in the gdb protocol that they know they're attached and ready to go.  If we have an analog on the Windows side, is it just a matter of exposing that for the client code that attaches to the lldb-server/debugserver/{windows-equivalent}-server?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 3:09 PM, Zachary Turner via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Assuming we can find a reasonable way to detect this on all platforms, can I replace current wait-for-debugger-attach code in the test inferiors to use this method?  It's all very racy right now, and there are combinations of sleeps and loops in the executables sometimes working together with sleeps in the test cases to synchronize the test and the executable.  If we had a common method that allowed inferiors to just say "wait until some debugger is attached to me" I think some of our problems would go away.<div><br></div><div>Would you mind posting a code snippet for how to do this on OS X so someone familiar with FreeBSD and/or Linux can comment on if there's a similar one for their platform?</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 26, 2015 at 3:04 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is a way on OS X.  There is a sysctl that will give you information on the current process state, and one of the bits you get back says whether the process is being traced.  sysctl's are a generic UNIX thing, but I don't know if the bit OS X uses is shared with other Unix's.<br>
<br>
Jim<br>
<br>
> On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Slightly related, but do other platforms have a way to check from an inferior if a debugger is present?<br>
><br>
> We need to do this frequently from the test inferiors, and I see lots of different approaches used in the test programs, none of which work correctly on Windows.<br>
><br>
> On Wed, Aug 26, 2015 at 2:09 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> On Windows, when we attach to process, we basically invoke a system call which tells the kernel to kick off the process necessary for a debugger to be able to communicate with the process.<br>
><br>
> The end result of all this is that eventually the OS itself will generate a breakpoint in the inferior by injecting an additional thread into the inferior and breaking on that thread.<br>
><br>
> LLDB picks this up, and the result is that LLDB stops and waits for the user to continue the inferior just as it would with any other breakpoint, and if you were to get a backtrace you might see something like this:<br>
><br>
> looking at: Stack traces for SBProcess: pid = 12588, state = stopped, threads = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api<br>
> Stack trace for thread id=0x3428 name=None queue=None stop reason=none<br>
>   frame #0: 0xffffffffffffffff ntdll.dll`DbgBreakPoint + 1<br>
><br>
> Stack trace for thread id=0x4314 name=None queue=None stop reason=none<br>
>   frame #0: 0x00000077908c2c None`None + -18446744071703589843<br>
><br>
><br>
> My question is: Do other platforms have this concept of an OS-generated breakpoint?  Or when you attach to the process, would the first breakpoint opcode encountered by the inferior be one which was created by the user through some command from the debugger?<br>
><br>
> This creates a problem for some of our tests, because we have this extra breakpoint that is messing up the stack frame expectations unless we issue a manual continue first to get past the initial breakpoitn and to the first user breakpoint.<br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=aTCVT7yw0RLKhx7ZXY2faboS3m1dhXpYF-Av4XoSGMU&m=VvFNLC1Qe6kBmEoVqGF9NZIVrDnFQZBDYfsUdMRn1aE&s=9o1ODu6v5nQisbSZVZpKU56ZDygZTcK6a_1juRJLhis&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=aTCVT7yw0RLKhx7ZXY2faboS3m1dhXpYF-Av4XoSGMU&m=VvFNLC1Qe6kBmEoVqGF9NZIVrDnFQZBDYfsUdMRn1aE&s=9o1ODu6v5nQisbSZVZpKU56ZDygZTcK6a_1juRJLhis&e=</a><br>
<br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>