> 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
