cvs commit: src/gnu/usr.bin/binutils/libbfd/i386 bfd.h
marcel at xcllnt.net
Sun Apr 18 13:59:43 PDT 2004
On Sun, Apr 18, 2004 at 10:53:50AM -0700, David O'Brien wrote:
> > Yes, I'll import to gdb6
> Please don't do this -- I'll ask Core for a backout.
Make sure you tell them what you want to see backed out, who is
going to do it and why core needs to be asked about it. They
might think you're a whiner otherwise.
> I know how bad the
> trys at this were before. gdb6 can be tested just fine in ports.
Bullshit. gdb depends on bfd, opcodes and libiberty. All three are
part of binutils and you don't test gdb with the binutils we have
in the tree in you test the port or test outside the tree without
also importing a new binutils.
In fact, I've been asking for a binutils upgrade for a long time and
I don't think I have to tell you how easy it is to get the maintainer
See also below.
> If the gdb52 port doesn't do all that
> src/contrib/gdb does, they can find the missing bits in CVS and add
> patches to the port.
??????? If it's already impossible to get committers to cooperate
and invest time in something that's not currently their pet peeve,
(like trying to get you to upgrade binutils) and user testing is
pretty much non-existent if you don't force the code down their
throat, then the extend of your stupidity to actually suggest that
people collect bits from various places and make a working gdb out
of it is beyond my sublime capability to comprehend large concepts.
> > > Import it just as src/contrib/gdb.
> > No. There are too many dependencies.
> What are they?
o binutils: most importantly bfd, but the gdb testsuite does depend
on having a good assembler to avoid bogus failures.
o light-weight processes in the context of libpthread and libthr and
how they affect core files. This too may cause changes to bfd to
support any new notes we may need (such as NT_LWPSTATUS).
o Support for libpthread and libthr as well as libc_r in general.
This depends on a new library, libthread_db, and possibly (likely)
needs changes to gdb that need to be contributed back. Not to
mention that changes to KSE, libpthread and libthr are also needed.
There are ABI breakages to be expected here.
o Remote debugging the kernel and the bogus dependency on sio(4).
The sio(4) driver is too broken to support all platforms and the
remote debugging capability is important to have. Not to mention
that a more generic approach also allows us to debug over firewire
o New platforms: amd64, ia64 and sparc64. Support for gdb is mostly
untested or otherwise in an unknown state. Understanding what works
and what doesn't work takes time and is likely to trigger changes
to the platforms and/or gdb.
o Kernel modules. I haven't paid any attention to Peter's work yet,
but I'm not at all surprised that it may affect the various hacks
we have in that area. We need to be responsive or at least prepared.
o Kernel threads. The kernel threads are not visible in gdb because
it's new functionality. It's important to have support for that.
This affects remote kernel debugging.
o TLS. I don't think there's anything in gdb that we need for this,
but TLS affects binutils, RTLD, kernel, libthread_db and threading
libraries. No doubt that gdb support may have an effect on how we
o Last but not least; all the above is affected by having a gdb
upgrade in between. Do you wait for gdb to be upgraded before you
work on some part or does gdb depend on that part and do you need
to prototype it first with the existing gdb.
The point is that kernel, threading libraries, system headers, gdb
and binutils need changes. Not each on their own and independent of
each other, but triggered and affected by each other. This makes it
a highly volatile cross-discipline problem that cannot be solved
without planning and collaboration. And it definitely cannot be
solved if you pull one element ot of the mix and develop it on the
side-lines. Since we don't have much time and resources, planning
is crucial. Unfortunately, even that is has been demonstrated to
Marcel Moolenaar USPA: A-39004 marcel at xcllnt.net
More information about the cvs-src