A better way, rather than messing with signals, is to simply use a pipe
between the parent and child to indicate when they're both ready.
Richard Mitton
[email protected]
On 07/24/2014 11:28 AM, Greg Clayton wrote:
On Jul 23, 2014, at 4:44 PM, Todd R. Fiala <[email protected]> wrote:
Hey Greg,
I’m looking into implementing process start-up so I can just follow your flow
of launching the exe, then connecting via llgs with reverse connect. I’d like
to take a shot at getting Linux processes to start up in a “stopped at initial
entry point” behavior rather than doing something different than MacOSX at this
point.
Linux PTRACE doesn’t provide this out of the box. There is an alternative that
could work but is not reliable across Linux kernel versions: detaching from a
PTRACE’d exe during a group-stop will leave it stopped. I think the initial
startup signal I get with PTRACE may yield a group stop. If it’s not, I can
immediately turn around and issue a stop, deliver that and get the real group
stop. (Not 100% sure I could do that last part with guaranteed no-execution
semantics at the entry point location). Unfortunately, the detach is not
reliable everywhere I need this to run to keep the process in a stopped state
at that point for handoff to llgs.
What I could do instead, is fork, and have the child process self-send a
SIGSTOP before doing the exec. And, on Linux (and maybe FreeBSD), when llgs
attaches, it just needs to know that it has to wait for one exec signal before
the process really starts. (I’m not sure if there is a shell mode for debugging
with Linux - if there is, then we need to exec through the shell script too, I
think — I don’t remember seeing that on the linux code path so it likely is
buggy and/or unsupported at the moment). In any event, if I do this, I’m
pretty sure I can guarantee that I can start a process in debug-ready mode with
the caveat that there is an exec that has to be silently ignored when llgs
attaches.
How does that sound? Thoughts?
The idea sounds good, as you can just do:
kill(getpid(), SIGSTOP)
but you can run into problems with the foreground app in a terminal not being
able to SIGSTOP itself and you might get some SIGTTOU or SIGTTIN signals.
But do try it out. The ProcessLaunchInfo have:
uint32_t
GetResumeCount () const
{
return m_resume_count;
}
void
SetResumeCount (uint32_t c)
{
m_resume_count = c;
}
So you just need to set this to 1 and it will continue past 1 exec without
trying to read the dyld info for any execs before m_resume_count gets to zero.
Greg
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
