cvs commit: src/gnu/usr.bin/binutils/libbfd/i386 bfd.h

Marcel Moolenaar marcel at
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
to cooperate.

See also below.

> If the gdb52 port doesn't do all that
> src/contrib/gdb[52] 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
   or ethernet.
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
   implement that.
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
be impossible.

 Marcel Moolenaar	  USPA: A-39004		 marcel at

More information about the cvs-src mailing list