I think it's mostly a problem of tests. Basically we have tests which are
written in such a way that the inferior and the debugger need to reach a
synchronization point before the test can proceed to test what it wants to
test.
On Mon, Aug 31, 2015 at 4:08 PM Greg Clayton wrote:
> Or is this ju
Or is this just a problem with a bad test? Are we telling LLDB to launch the
test and LLDB is doing the launch + attach in the windows platform and that is
what is hosing up the attach? Or is this a flawed test where the test just
manually launches the process with no hopes of syncing with the p
So a few things:
1 - on MacOSX we can reliably launch a process via posix_spawn() with a flag
set that sets the process to stop at __dyld_start which is the first
instruction in the program. So our launch then attach always works reliably
because when we launch the process set set this posix_sp
On Thu, Aug 27, 2015 at 3:01 PM, via lldb-dev
wrote:
> On Thu, Aug 27, 2015 at 05:05:23PM +, Zachary Turner via lldb-dev
> wrote:
> > Well I'm xfailing it for now, but this other method seems kind of hackish
> > to me because it means the inferior and the debugger have to coordinate
> > with
On Thu, Aug 27, 2015 at 10:17:24PM +, Zachary Turner wrote:
> In what instances do you think it wouldn't work? At least on Windows it's
> trivial. Jim provided some code that would work on OSX, and someone else
> provided a method earlier in the thread that should work for Linux. What
> are
In what instances do you think it wouldn't work? At least on Windows it's
trivial. Jim provided some code that would work on OSX, and someone else
provided a method earlier in the thread that should work for Linux. What
are the specific reliability concerns you have?
Changing lldb to prever deb
On Thu, Aug 27, 2015 at 05:05:23PM +, Zachary Turner via lldb-dev wrote:
> Well I'm xfailing it for now, but this other method seems kind of hackish
> to me because it means the inferior and the debugger have to coordinate
> with each other, which means the test has to know about the executable
Well I'm xfailing it for now, but this other method seems kind of hackish
to me because it means the inferior and the debugger have to coordinate
with each other, which means the test has to know about the executable and
the executable has to know about the test. I'd rather remove one direction
of
Ah yes, our old friend TestHelloWorld. This guy definitely needs to be
fixed. I haven't actually looked at the code before to see why it was
so flaky, but now it all makes sense
I would just use the "usual" protocol of "expr release_child = 1"
here, but if you wanna go crazy, then go ahead...
It's not that it relies on a specific thread being selected, because as you
can see there are 2 threads in that trace. The problem is that the second
frame is not even yet in the main function, it's in the startup code
because of how early the attach process happens (which itsels is probably
actua
The main issue I see with all these APIs is that they are
non-blocking. That is, the test executable cannot simply say "wait
until a debugger attaches", but it will have to do something like:
while (! attached) {
sleep(X);
attached = figure_out_if_i_am_attached_using_architecture_specific_metho
>
> On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev
> 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
lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim Ingham
via lldb-dev
Sent: Wednesday, August 26, 2015 5:26 PM
To: Zachary Turner
Cc: LLDB
Subject: Re: [lldb-dev] How does attach work on non-Windows?
There's even a Tech Note for how to do this:
https://developer.apple.com/library
There's even a Tech Note for how to do this:
https://developer.apple.com/library/ios/qa/qa1361/_index.html
I think you should be able to see that w/o a developer account, but if you
can't, here's the code:
#include
#include
#include
#include
#include
static bool AmIBeingDebugged(void)
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
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
sleep
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
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 he
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
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 inj
20 matches
Mail list logo
