This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix Linux attach to signalled/stopped processes

> PTRACE_KILL; that only sets the exit_code and wakes the process but at

PTRACE_KILL is completely useless AFAIK.  Sending SIGKILL with kill always
works (except in a few buggy kernels from a short window a few years ago).

> I feel like there's a kernel bug here somewhere, but it's buried in
> the depths of poorly defined ptrace semantics, so maybe not.  I think
> it prudent not to deliberately put things into the job-control stop
> state because of this limitation.

There isn't really any entirely satisfactory definition of "right" I can
find, because it's just so wrong that the real parent will never see
CLD_CONTINUED or CLD_STOPPED indicators no matter what.  I gave up on
ptrace meaning anything other than whatever it has stably meant for kernels
in use for a good while.

> What we need is to get from the job control stopped state, back into
> the signal delivery stopped state.  Jan's artificially delivered
> SIGCONT is the only way I can think of to do this.

Or you can use any unblocked signal with tkill to get one pending and then
PTRACE_CONT,tid,0,0 to force the wakeup.  Generating SIGCONT (blocked or
not) will wake up all the threads in the process, which may not be what you
want.  You could use a signal >= SIGRTMIN to get your synthetic one queued
separately from any that might already be there, and then recognize yours
by si_pid when you see it stop.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]