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

[Jim Ingham via lldb-dev]

On OS X and most Unixes, you call ptrace(pid, PT_ATTACH) or some procfs call to initiate the attach, and then wait on the pid until it comes back with a SIGSTOP signal when the attach is completed.  How the wait is done differs from system to system, but this is the general model.  I have not heard of a UNIX that uses actual trap instructions placed by the kernel in the process to stop it.

Jim

> On Aug 26, 2015, at 2:09 PM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> 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 at 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=L-3KeVaOuHZA0PFZErpqOUVyPGhnBc0qTlAnlY2nL8A&s=dSTTA6Jqz1P1PNsAHJN-99X-FdcVufV3UTWsB3Defx0&e=