Re: GDB - do we dare?

   Date: Fri, 11 Jul 2003 15:50:02 -0700
   From: Marcel Moolenaar <marcel_at_xcllnt.net>

   Gang,

   With the gcc(1) dust not even settled yet, I like to get some feedback
   on gdb(1). AFAICT, this is the deal:

   o  Both ia64 and amd64 need gdb(1) support before they can become a
      tier 1 platform. I think this implies upgrading to 5.3 the least.

Upgrading to 5.3 for amd64 won't really help.  While 5.3 included
support for amd64, I'm told it is seriously broken.  Since then, I've
almost completely reworked GDB's amd64 target, to bring it in line
with the i386 target, and adapt it to some major architectural changes
in GDB.  Based on that work, I've finished a FreeBSD/amd64 port
yesterday.  I'll try to get it on GDB's 6.0 release branch.  However,
backporting it to 5.3 would be a major PITA and IMHO a tremendous
waste of effort.

   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.

   o  With libkse and libthr in the tree, we probably want to keep close
      to the latest gdb(1) development to benefit from the threading
      work that's likely to be done and also make sure we add whatever we
      need to support our threading models.

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.

Note that there isn't much development on thread-related GDB stuff.
The Linux folks are still chasing bugs, mainly because there are no
sane kernel interfaces for debugging threads and the kernel interfaces
keep changing.  I'm confident we can avoid that mess on FreeBSD ;-).

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

   o  The new gcc(1) also adds support for TLS, which, if time is with
      us may be supported by both libkse and libthr before R5.2 and may
      need some gdb(1) support as well. I don't know, but if it does,
      we probably want to add that to gdb 5.3 or later.

It's already working on Linux, so it should be easy to add support for
TLS for other platforms.

   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.

I think the diffs between 5.2 and 5.3 are negligible compared to the
the diffs between 5.3 and 6.0, at least for i386/amd64 and Alpha.

   I'd say: upgrade gdb(1) and add support for ia64 and amd64, as well
   as make sure we fix any known showstopper bugs we know of.

   Q1 How does that sound in general?
   Q2 Do we have people with sufficient background and motivation who
      want to volunteer to make this happen?

   Since the answer to Q2 is likely no or indetermined, I would like
   to emphasize that I do not expect this to be a one-man show. We
   really need to treat this as a project.

   Thoughts?

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.

A2 I'm volunteering to help out here.  As the i386 target maintainer
   and FreeBSD host/native maintainer, I seem to have sufficient
   background in GDB I guess ;-).  For almost two years now, I've been
   using FreeBSD/i386 as my primary (development) platform, and I hope
   at least some people have noticed that the upstream GDB works much
   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.  Although
   my primary development will be focussed on the upstream FSF GDB
   releases, I'm dedicated to FreeBSD, and I'm certainly willing to do
   work on integrating new versions of GDB into the FreeBSD tree.

Mark