GDB - do we dare?
Mark Kettenis
kettenis at chello.nl
Sat Jul 12 04:05:07 PDT 2003
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
More information about the freebsd-current
mailing list