Re: GDB 5.0 2000-03-05

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Jim Kingdon <kingdon@redhat.com>
   Date: 06 Mar 2000 09:08:48 -0800

   * Spurious SIGTRAP bug.  No one has diagnosed this bug as far as I
     know, although JimB was working on it.  This one is probably the most
     serious.

I cannot reproduce this on my Linux system.  Note that the SIGTRAPs
have been observed under other OSes too.  Somebody (you know ...) who
can reliably reproduce this should debug this.

   * lin-thread cannot handle thread exit.  Should we think about
     disabling lin-thread in favor of linux-thread for 5.0?  Or to put it
     another way, has lin-thread gotten enough testing?  There might
     be other variations on this theme, such as a note in the
     documentation about how deleting/renaming libthread_db might be a
     workaround, although I'm not sure that really helps much.

A fix would be preferred of course.  I really think moving the
thread_db assisted debugging is our only chance of having a GDB that
works reliably with different thread libraries.  But if it doesn't
work, we should disable it.  Fiddling with libthread_db might not be
an option for all users.

   * dlclose().  Any reactions MarkK?  Or JimB?  Note that issues50.html
     points to a withdrawn patch; the most recent is:
     http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00454.html

I think your latest patch looks fine to me.  I'm not sure if it will
work with FreeBSD, but that's not too important, since stock GDB doesn't
build on FreeBSD right now.

   * 2.0.x kernel patch.  MarkK?  issues50.html points to the latest
     patch on this as far as I know:
     http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00294.html

That's already fixed :-).  I'm almost through my backlog of Linux/i386
patches.  There are a few remaining issues like:

 * Stepping throught signal trampolines doesn't work very well.

I have a patch that makes `next' work, and I'll see if I can get
`step' working too.  Right now `step'-ing out of a signal handler and
through the signal trampoline will corrupt the inferior's stack, so
this is somewhat important to get fixed.

 * Processes started under GDB will have SIGCHLD blocked.

Makes some tests in the testsuite fail, and is possibly annoying, but
definitely not a show-stopper.

Mark


[1] The FreeBSD folks maintain their own version of GDB.  The GDB in
their tree is based on GDB 4.18.  Most of their changes are to files
that are specific to FreeBSD, but they also made changes to solib.c.
According the the CVS logs these were for supporting dlclose(), and
for dealing with some peculiarities of their dynamic linker.