Re: GDB - do we dare?

   Date: Sat, 12 Jul 2003 13:39:30 -0700
   From: Marcel Moolenaar <marcel_at_xcllnt.net>

   On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
   > 
   >    o  We still have the Alpha gdb -k bug moved over from the 5.1 todo
   >       list to the 5.2 todo list. I think this is "just" a bug fix.
   > 
   > I'm not really familliar with the support for debugging FreeBSD
   > kernels in GDB since that support is not in the FSF tree.  Is there
   > any chance that this code will be contributed back?  This would
   > involve a copyright assignment, which could prove to be a major
   > obstacle.

   The copyright of our kgdb support is already the FSF. See
   /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c

I'll have to find out whether the paperwork is actually there.

   > The current support for debuggung libc_r-based threading is also not
   > present in the FSF tree.  So the question raised above applies here too.

   It looks to me that it can be contributed back.

That would be great.

   > I'm not really familiar with KSE, but AFAIK the kernel interfaces for
   > debugging KSE's aren't there yet.

   I think that's mostly due to a knowledge gap. We just need people who
   can bridge between gdb and FreeBSD. Someone like you :-)

   >    o  gdb(1) has created a 6.x branch, so it's likely that a new release
   >       is in the pipeline (within 6 months?). Upgrading to 5.3 may make
   >       a future upgrade easier due to smaller diffs and refreshed know-how.
   > 
   > GDB 6.0 will defenitely be released before the end of the year :-).
   > We're aiming at the end of August, but it will probably be somewhere
   > in September.

   Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2
   scheduling wise. Do we need a binutils update? We now have 2.13.2.

Probably, yes.  FSF GDB releases use a libbfd that's basically a
snapshot taken at the point where the release branch was cut.  You
folks seem to try to get away with using libbfd from binutils.  This
usually works as long as the GDB and binutils releases used are not
too far apart, so it's more likely that this works if binutils is
updated.

Actually, I think you'll need binutils 2.14 anyway for TLS.

   > A1 If having support for amd64 is a major reason for doing a new
   >    import of GDB, importing the upcoming GDB 6.0 would make more sense
   >    to me.

   No ia64 is the major reason :-)

Hmm.  I think I just crashed pluto1 trying to get it to run the GDB
testsuite on a not-yet-fully-functional GDB port.  Currently RSE is
giving me some headaches.

   > A2 I'm volunteering to help out here.

   Cool, thanks. Shall we just create a p4 branch and start hacking?

Oh dear, do I need to learn another version control system?

Anyway, this can probably wait.  I'll be on vacation from next tuesday
until August 10, and I still have to do some work on the upstream GDB
sources before I can start thinking about integrating things in the
FreeBSD source tree.  The GDB sparc target has suffered some bit rot,
up to the point where it is hardly usable.

   >    better on FreeBSD/i386 and FreeBSD/Alpha now.  Now that I've got it
   >    working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot.

   We probably need to talk then, because the ptrace interface needs
   to be fleshed out and I planned to do that while porting gdb.

Probably.  The current layout of `struct reg' and `struct fpreg' is a
bit ... messy.

Mark