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: A patch for gnu-regex


"H . J . Lu" wrote:

> > A GNU/Linux distributor is free to build a GDB that regexp from an
> > installed glibc. Actually such a distributor is free to do what ever
> > they like :-)
> 
> Are you saying as far as gdb is concerned, you have no interests
> whatsoever in glibc nor helping glibc developers and GNU/Linux
> distributors? If it is true, that is too bad.

Let's not get all tense here!  There's a balance to be struck between
being self-contained and depending on system stuff, and there's no
single rule that applies in all cases.  For instance, GDB includes
libiberty, even though many of the functions are available on most
systems by default, including Linux, but I don't seem to hear anybody
complaining about that bit of redundancy.  (Hmmm, why isn't regex
in libiberty anyway??)

In the case of GDB on Linux, part of our problem is that we have
to support GDB on all versions of Linux, not just the latest
kernel and library.  So if there is *any* version of glibc with
a problematic regex, say one from 4-5 years ago, we need to think
hard about whether we're going to hose people running a Linux that
is that old.  GDB's rule has been to maximize compatibility with
a whole range of OS versions, and now that Linux has sailed past all
other OSes in number and variety of versions, it's really putting
our infrastructure to the test.

In this case, my inclination would be to rely on the glibc regex
by default.  GDB users don't tend to push the boundaries of regexps
in their daily debugging activities, and if recent glibcs are good,
then it's seems unlikely that we'll ever get any bug reports
stemming from regex problems.  So we'll be taking a bit of a chance,
but with the configuration option, and if we communicate to the glibc
folks that we're now always depending on their version to be correct,
I think things will work out OK.

Stan

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