This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: x86 fpu


> 
> 
>    Date: Wed, 20 Oct 1999 23:06:00 -0700 (PDT)
>    From: hjl@lucon.org (H.J. Lu)
> 
>    [...] It is a pain for me to maintain my
>    private versions. But I hate to see the Linux people nowhere to
>    go for help. Do you really honestly believe that a new official
>    version should be made whenever a serious Linux related bug is
>    fixed or we have to live with the bug which mainly affects Linux?
> 
> That's not necessarily a bad idea... If one were to look at which
> platform has the largest number of GDB-using programmers these days,
> it would most likely be GNU/Linux by far.  Why can't the GDB release

Please also remember that the GNU tools are the only ones GNU/Linux
get. If they don't work for us, we have to find a workaround one way
or the other.

> schedule be adjusted to accommodate the majority of users?

I am glad to see it is happening for gdb. Finally I can get rid of my
Linux version of gdb. I wish I could say the same for other tools.

BTW, I have sent in a patch for cplus-dem.c to the gcc patches mailing
list. It is/will be used by some of GNU/Linux tools. However, I have
a feeling that it will take forever to get accepted.

> 
>    I have been sending my patches to the appropriate people. But they
>    don't work only for Linux. My patches have to wait, but Linux cann't.
>    It is not that unusual to take a few months or more for my patches
>    to be installed.  What do we do?
> 
> This is the genesis of the situation.  Patch submissions should be
> acted upon promptly, whether to accept or reject.  It's my
> responsibility to see that this happens, and if I fail at that,
> I'm not going to fault anyone for coming up with workarounds like
> splinter versions.

Sometimes, it takes a splinter version to get things done and we have
to take the consequences. I am not proud of the Linux C library 5. I
wish it had never happened. But without it, we may never have Linux
nor glibc 2 today.

> 
> I hope everybody agrees that patch turnaround has improved over the
> past several months.  It's still not where it should be; if you feel a
> worthy patch is being ignored, please send me mail with lots of
> capital letters and exclamation points, or call me on the phone at
> +1 408 542 9678.

I will send in a few patches after x86 fpu is resolved.

> 
>    I will work with everyone to merge my changes. But it doesn't mean
>    I will stop working for the Linux community. We have different
>    priorities. That is life.
> 
> This should not be true however.  I used to think this myself, until
> RMS pointed out that since Linux is one of the official kernels for
> the GNU system, GDB support for it ought to be a higher priority than
> support for non-GNU systems.  Of course, GDB is still free software
> like always, and I still want to encourage people to contribute
> improvements for non-GNU systems as well.
> 
> Lately, Jim Blandy and Jim Kingdon have stepped up to the task of
> making sure the FSF version of GDB is fully functional for GNU/Linux,
> and there has been considerable progress, as witness the discussion of
> x86 float support.  Also, Scott Bambrough has been hard at work on
> Netwinder (ARM) support, and Kevin Buettner is on PowerPC.  At this
> rate, I expect that the upcoming 5.0 release will be the version of
> choice for GNU/Linux.

First is glibc, now is gdb. What are the next? binutils and gcc? I
am not holding my breath.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]