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

[Marcel Moolenaar]

On Mon, Apr 19, 2004 at 03:28:12AM -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.

What I don't understand is the part about trying. It's not more
difficult to import in gdb6 than it is to import in gdb. So what
exactly did need people need to try? Are you talking about the
same thing I'm talking about or are you reacting on some association?

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

No, I gave them. I even send you a file and version number of the
change that was made specificly for FreeBSD/ia64. You acknowledged
this:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/emulparams/elf64_ia64_fbsd.sh?cvsroot=src

As you can see, version 1.2 is dated 11/28/2003. It's april now. You
do the math.

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

Your commitment is purely based on your terms without considering
other peoples needs. Even with your commitment you're keeping me
from doing what I need to do. But I'm sure you can't see that, so
I don't see any point trying to make that clear to you.

> > 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)?

Why do you always have to jump the gun? Nobody is asking you. In
fact, the reason I plan to import in gdb6 is that I also import BFD
and other (small) parts of binutils so that we can experiment and
build a workable debugger without endangering anything. You might
want to start assuming that I actually did give it some thought or
actually do have some experience in this...

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

The hold-up is that it's another source of non-cooperation and
misunderstanding. Both are needed if you want to do it right the
second time (lib/libpthread_dbg is the first time).

> >    There are ABI breakages to be expected here.
> 
> Then we'd all probably like to hear your plans for mitigating this.

I'm not doing the work. I'm just telling you 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.

Most of the work has already been done without having gdb in the tree.
It's time to work on the intergration because there's too little firm
ground.

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

I don't have to second guess his work, because I know he doesn't test
with our local patches. So, whatever he wrote is not what's going to
end up being installed on a FreeBSD box as-is. There's no KVM, no
libc_r, no kgdb and no kernel modules support in stock gdb. Also,
Mark ports based on what is currently present in the kernel. We don't
write notes for the SSE registers in the core file on i386, so he can
not have tested that. That's not his fault, but it means that gdb on
FreeBSD is likely not feature equivalent to gdb on Linux.

So, David, exactly how good is our debugger then?

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

Where possible, the work has already been done outside the tree. The
problem is completion. You need to start committing things to reduce
the number of balls you have in the air. It's like juggling. If you
imagine that I'm using your balls as well, you might appreciate more
that I'm trying not to drop them and accidently step on them.
Everything is volatile now and there's basicly no progress because of
that. No progress means that it will not be finished in time for 5.3,
which then automaticly means that FreeBSD 5.3 cannot possibly be the
start of -stable; if you want to take yourself seriously of course. I
admit that it's an assumption I've made. Feel free to correct me here.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net