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 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
