This is the mail archive of the gdb-patches@sourceware.org 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: FYI: fix 2 tests when glibc debuginfo is installed


On Tuesday 25 October 2011 18:32:49, Oleg Nesterov wrote:
> On 10/25, Pedro Alves wrote:

> > Thanks.  Okay, so I take it what really happens is that PTRACE_ATTACH no
> > longer messes with job control,
> 
> Well, PTRACE_ATTACH was not really changed in this sense. 

Ah, okay.

> And it still sends SIGSTOP.  You can use PTRACE_SEIZE.

That I know.  :-)  I was trying to understand what happens
to older gdb's on new kernels, and, if gdb needs to adapt,
and if it needs to detect whether what "flavor" of
PTRACE_ATTACH|DETACH it is talking to.

> But I guess this is off-topic,

> > and that gdb will have to
> > `kill -SIGCONT' the inferior itself if it wants e.g., inferior
> > function calls to work after attaching to a stopped process
> 
> Why? PTRACE_CONT/etc should work. The tracee will be resumed, stopped
> or not. 

Eh, well, I read some discussions from earlier this year on
lkml proposing that, and I guess I got confused.

> But, compared to the old kernels, the tracee "remembers" the
> fact it was stopped, and it will stop again after DETACH. Unless SIGCONT
> in between.

What about PTRACE_CONT in between (no SIGCONT)?  Does it make the
kernel "forget" the fact that the child was stopped before?
If not, what happens if the ptracer dies while its child
is PTRACE_CONT'ed, and the child was stopped at PTRACE_ATTACH time?

-- 
Pedro Alves


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