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

[David O'Brien]

On Sun, Apr 18, 2004 at 01:59:42PM -0700, Marcel Moolenaar wrote:
> 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 don't need to -- the proof is still in /home/ncvs.  We tried this in
the past and it as a BIG, HUGE mistake.  I'm sure Peter (you know the
Core guy) still fully remembers the PITA and mistake it was.


> > 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.
...
> (like trying to get you to upgrade binutils) and user testing is

I've asked you repeatedly for real details of the need for the code
churn.  You've failed repeatedly to give them.  Only Scottl has worked to
ensure a binutils import isn't just code churn and a waste of my time.

You already have a commitment from me to do it; so you can stop
mentioning this as something keeping you from what ever.


> > > > Import it just as src/contrib/gdb.
> > > 
> > > No. There are too many dependencies.
> > 
> > What are they?
>
> 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).

I can tell you right now I'm not pulling bfd off the vendor branch for
this.  Why aren't you experimenting and submitting diffs to the Binutils
patch list (or me to submit them in your behalf)?

> 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.

Since we have no src/lib/libthread_db right now, what's the hold up with
committing it now or when it is ready?  What does this have to do with
not being able to build your super-duper GDB from /usr/ports?

>    There are ABI breakages to be expected here.

Then we'd all probably like to hear your plans for mitigating this.

> 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.

Again you're bringing up something that can be worked on separately, and
doesn't require your super-duper GDB to be in /usr/src to do this.

> 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.

Mark Kettenis (a main GDB author) rewrote the BSD UltraSparc support,
along with wrote the new AMD64 support.  I personally sent him an
Athlon64 system to do this work.  I don't see the need to second guess
Mark's work.  I'm also sure any bugs that anyone may find will be fixed
with good responsiveness.

..rest of list snipped..

You've got a very good list of things that need to happen.
But you've failed to convince why you can't test all the things but
putting the new bits first into /usr/ports.  Please address that.

-- 
-- David  (obrien at FreeBSD.org)