Date: Sun, 18 Apr 2004 13:59:42 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: "David O'Brien" <obrien@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/binutils/libbfd/i386 bfd.h Message-ID: <20040418205942.GA65385@dhcp01.pn.xcllnt.net> In-Reply-To: <20040418175350.GA65307@dragon.nuxi.com> References: <200404181609.i3IG9XA1099515@repoman.freebsd.org> <20040418162431.GI12383@ip.net.ua> <20040418163301.GA64947@dhcp01.pn.xcllnt.net> <20040418164651.GB62817@dragon.nuxi.com> <20040418170730.GB65020@dhcp01.pn.xcllnt.net> <20040418175350.GA65307@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040418205942.GA65385>