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.
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?
On Wed, Aug 26, 2015 at 3:09 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> 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.
>
> 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?
>
> On Wed, Aug 26, 2015 at 3:04 PM Jim Ingham <jing...@apple.com> wrote:
>
>> 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.
>>
>> Jim
>>
>> > On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Slightly related, but do other platforms have a way to check from an
>> inferior if a debugger is present?
>> >
>> > 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.
>> >
>> > On Wed, Aug 26, 2015 at 2:09 PM Zachary Turner <ztur...@google.com>
>> wrote:
>> > 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.
>> >
>> > 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.
>> >
>> > 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:
>> >
>> > looking at: Stack traces for SBProcess: pid = 12588, state = stopped,
>> threads = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api
>> > Stack trace for thread id=0x3428 name=None queue=None stop reason=none
>> > frame #0: 0xffffffffffffffff ntdll.dll`DbgBreakPoint + 1
>> >
>> > Stack trace for thread id=0x4314 name=None queue=None stop reason=none
>> > frame #0: 0x00000077908c2c None`None + -18446744071703589843
>> >
>> >
>> > 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?
>> >
>> > 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.
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> >
>> 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=
>>
>>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
--
-Todd
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
