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
