[lldb-dev] How does attach work on non-Windows?

[Zachary Turner via lldb-dev]

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 <zturner at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150826/16b2a28f/attachment.html>