This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: gdb-6.7-bz233852-attach-signalled-fix.patch
On Fri, 25 Jul 2008 04:54:58 +0200, Daniel Jacobowitz wrote:
> On Thu, Jul 24, 2008 at 05:41:23PM -0700, Roland McGrath wrote:
> > To wit, I came across something I wasn't expecting in GDB today
> > and it turned out to be code in a Fedora patch that's not upstream.
> > I'm using gdb-6.8-11.fc9.x86_64, and the code in question comes from
> > gdb-6.7-bz233852-attach-signalled-fix.patch.
>
> FYI, assuming the Fedora packages are actually based on 6.8 and not
> HEAD, please compare this with the version currently in HEAD;
Yes, gdb-6.8, HEAD and gdb-6.8-11.fc9 have all very different code for
handling the signals. The bug of gdb-6.8-11.fc9 described by Roland is
https://bugzilla.redhat.com/show_bug.cgi?id=453688
(Valgrind doesn't work with GDB properly)
which has been worked on but I could not finish the right patch as I usually
got unexpected SIG0 while coding/testing it due to the utrace kernel bug
https://bugzilla.redhat.com/show_bug.cgi?id=454156
(waitpid sometimes returns inappropriate SIG0)
and in fact it cannot work right due to the upstream + utrace kernel bug
https://bugzilla.redhat.com/show_bug.cgi?id=454404
(PTRACE_DETACH (..., SIGSTOP) does not stop it)
There is a long-term requirement for RHEL (->Fedora) GDB to transparently
attach+detach a stopped process as it worked for pre-utrace && old kernels
(RHEL-4) but the detach-as-stopped part is not handled by the current upstream
GDB. Unfortunately it is even not possible for GDB with the current upstream
kernels (rh454404).
Coincidentally yesterday I gave up trying to workaround the kernel bugs and
rather just temporarily removed the Fedora patch for gdb-6.8-12.fc9
https://admin.fedoraproject.org/updates/F9/FEDORA-2008-6744
to get there the gdb-6.8 behavior and I am waiting for the kernel fixes.
After the kernel fixes get in the patch being prepared should work as:
(attaching to a stopped process)
Attaching to process 18748
Program received signal SIGSTOP, Stopped (signal).
...
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
LND: Sending signal 19 to process 18748
Detaching from program: /bin/sleep, process 18748
or if I do `cont':
(attaching to a stopped process)
Attaching to process 18748
Program received signal SIGSTOP, Stopped (signal).
...
(gdb) c
Continuing.
Program received signal SIGSTOP, Stopped (signal).
[Switching to Thread 0x7f7ba68ed6f0 (LWP 18748)]
0x0000003e7b6a6390 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000003e7b6a6390 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /bin/sleep, process 18748
with a possibility of explicit (currently not implemented upstream):
(gdb) detach SIGSTOP
LND: Sending signal 19 to process 18748
Detaching from program: /bin/sleep, process 18748
> Reading through your message the strace on HEAD will look different,
> and if I understand correctly it will not have the same problem.
Yes, thanks, your code cleaned up / rewrote that my attaching part a lot.
On Fri, 25 Jul 2008 02:41:23 +0200, Roland McGrath wrote:
> I hope one of the first orders of business, before the fancy stuff,
> will be to feed all the work in the Fedora gdb that's not upstream
> through the group's review and reconcile all that work into a branch
> in the Archer project and unify the tracks of pushing fixes upstream.
Yes, it would be nice to sync it. I am open for advices what should I do to
make it possible. I should be more reviewing upstream but I usually do not
see the bugs in existing code and I would find it more as nitpicks (below).
Sometimes I spend a lot of time to split the patch and create a ChangeLog just
for upstream, such as (there were many others):
http://sourceware.org/ml/gdb-patches/2007-11/msg00438.html
with later no single response. I understand it would need a lot of changes to
find a consensus and I assume there is not enough free workforce upstream.
Sometimes I do not understand the upstream preferences
http://sourceware.org/ml/gdb-patches/2008-05/msg00166.html
and also some of the patch adjustments I find more as nitpicks
http://sourceware.org/ml/gdb-patches/2008-06/msg00476.html
with the existing deficiencies of no memory management (reference counting)
http://sourceware.org/ml/gdb-patches/2008-07/msg00097.html
and no generic OO framework (a stopper only for potential GDB newcomers).
I even still do not understand the meaning of the GNU ChangeLog content
describing the patch lines by words. Why? We have Bonsai and `cvs diff'.
The ChangeLog should just describe an intention of the patch which I still
miss in the current ChangeLog.
Regards,
Jan