This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Next release


"Weddington, Eric" wrote:

> That always seemed like anomalies to me. What good is it to have support for a target in binutils, but not in gcc, and vice versa.

Why should users of operating systems like OS X, Solaris 10, HP-UX, AIX,
etc. be denied the ability to use gcc just because the GNU assembler or
GNU linker hasn't been ported to those proprietary systems (or lack
certain features only present in the vendor tools)?  If using gcc also
required a FSF port of the assembler and linker then a whole lot of
users would be out of luck.  This is a valuable feature of the "only a
compiler" design of gcc.

> And it could be argued that that freedom is of marginal usefulness, at best. Is binutils *that* much buggier than gcc, that it is *so* incredibly useful to decouple the two to upgrade the assembler and linker with bug fixes, separate from gcc? At this point, gcc releases more often than binutils... I've seen more frequent gdb releases than binutils.

My point wasn't that one is more buggy than the other.  It's that
changing from gcc X.Y to X.Z can involve a nontrivial amount of
user-visible changes, particularly with regards to strictness and
semantics.  The newest gcc versions are fierce and merciless to code
that's not 100% language-lawyerly ISO correct where older versions let
it slip.  Code has to be ported and tested; unintended undefined
behavior has to be hunted down and rewritten or compile options
adjusted; it's far from a drop-in replacement.  On the other hand, the
assembler and linker have much less room for variance and should ideally
have no detectable effect on language strictness or semantics.  Thus
being able to pick up bugfixes and performance enhancements in the
assembler and linker (and miscellaneous related tools like readelf,
strip, objdump, etc) without also having to also evaluate a whole bunch
of potentially major compiler changes is a significant win, IMHO.

Brian


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