This is the mail archive of the
mailing list for the GDB project.
Re: [patch] Fix Linux attach to signalled/stopped processes
> Date: Tue, 26 Jun 2007 23:03:41 +0200
> From: Jan Kratochvil <firstname.lastname@example.org>
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> On Fri, 15 Jun 2007 20:01:59 +0200, Mark Kettenis wrote:
> > > Date: Wed, 6 Jun 2007 16:34:32 +0200
> > > From: Jan Kratochvil <email@example.com>
> > >
> > > The patch changes the functionality of TO_ATTACH. The former
> > > functionality was too UNIX centric. I was reading all the TO_ATTACH
> > > OS-flavor implementations and I believe the non-"inf-ptrace.c" ones
> > > do not need update. The code was tested only on Linux kernel,
> > > though.
> > I disagree here. You're adding all sorts of goo to work around
> > Linux-specific problems. Please put this stuff in linux-nat.c
> While that "/proc/PID/status" reading part looks definitely Linux specific
> I would guess that the first waitpid(2) after PTRACE_ATTACH may not return
> SIGSTOP even on other ptrace(2)-using OSes (BSD?).
It's not unimaginable that there are races, but I think it is wrong
for GDB to make things worse by sending signals itself. We have to do
that on Linux because it has totally inadequate support for denugging
threaded processes, but we really should restrict this madness to
> Attaching a testcase for a possible non-Linux kernel test which:
> Should print approx. 1x '.' per second (on each caught pending
> SIGALRM signal). At least Linux 2.6.22-rc5.x86_64 prints '!' which
> looks as a kernel bug to me.
This is what I get on OpenBSD:
.assertion "!WIFSIGNALED (status)" failed: file "ptrace-test.c", line 122, function "main"
Abort trap (core dumped)
This is sort of odd, but then your test program has a serious problem.
It doesn't wait(2) after ptrace(PT_ATTACH, ...). That's asking for trouble.
> How does currently GDB behave there while attaching to a SIGSTOPped process?
I don't think it matters whether the process is stopped or not.