backward/forward compatibility of binutils

backward/forward compatibility of binutils

[Mikhail Teterin]

Hello!

I apologize in advance for the potential explosiveness of this subject... :-)

I use FreeBSD, which uses a fair amount of binutils-using GNU utilities (gdb, 
compiler toolchain, objdump).

Currently each of these tools builds its own version of binutils and links 
with it -- *statically*. The binutils library(ies) (-lbfd) don't even get 
installed into /usr .

The reasons for this are historical -- each tool (still!) comes with its own 
version of binutils, which some time ago used to be incompatible with each 
other :-(

Is this still a problem, or should we try using a single version again?

Thanks!

	-mi

Re: backward/forward compatibility of binutils

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Fri, 2006-07-07 02:50:16 -0400, Mikhail Teterin <mi+kde@aldan.algebra.com> wrote:
> Currently each of these tools builds its own version of binutils and links 
> with it -- *statically*. The binutils library(ies) (-lbfd) don't even get 
> installed into /usr .
> 
> The reasons for this are historical -- each tool (still!) comes with its own 
> version of binutils, which some time ago used to be incompatible with each 
> other :-(

Especially for the libbfd, the reason is probably that it was agreed
to not keep a specific binary interface, thus, there's not much sense
in keeping an eye on what patches are bugfixes-only and those that
alter the binary interface, which require to increase the library's
version number.

On the other hand, those patches didn't happen that often, so one
probably _could_ do that.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: backward/forward compatibility of binutils

[Daniel Jacobowitz]

On Fri, Jul 07, 2006 at 02:51:12PM +0200, Jan-Benedict Glaw wrote:
> On the other hand, those patches didn't happen that often, so one
> probably _could_ do that.

... but when it breaks, you get to keep both pieces.

I'd ask that if you want to ship a libbfd for public use, only ship the
static library.  It may be useful to ship the dynamic library, if only
because it saves a lot of space in as/ld/objcopy/objdump/strip, but gdb
may not want the same copy.

-- 
Daniel Jacobowitz
CodeSourcery

Re: backward/forward compatibility of binutils

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Fri, 2006-07-07 09:22:23 -0400, Daniel Jacobowitz <drow@false.org> wrote:
> On Fri, Jul 07, 2006 at 02:51:12PM +0200, Jan-Benedict Glaw wrote:
> > On the other hand, those patches didn't happen that often, so one
> > probably _could_ do that.
> 
> ... but when it breaks, you get to keep both pieces.

Of course. I didn't mention that it would be a nice thing to have. I'm
actually opposed to it.

> I'd ask that if you want to ship a libbfd for public use, only ship the
> static library.  It may be useful to ship the dynamic library, if only
> because it saves a lot of space in as/ld/objcopy/objdump/strip, but gdb
> may not want the same copy.

Full ACK.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: backward/forward compatibility of binutils

[Mikhail Teterin]

On Friday 07 July 2006 09:27, Jan-Benedict Glaw wrote:
= Of course. I didn't mention that it would be a nice thing to have. I'm
= actually opposed to it.

Why not? How hard is it to keep API compatibility (no need for ABI)? Why do 
you insist on every tool bundling its own version?

	-mi 

Re: backward/forward compatibility of binutils

[Daniel Jacobowitz]

On Fri, Jul 07, 2006 at 10:44:22AM -0400, Mikhail Teterin wrote:
> On Friday 07 July 2006 09:27, Jan-Benedict Glaw wrote:
> = Of course. I didn't mention that it would be a nice thing to have. I'm
> = actually opposed to it.
> 
> Why not? How hard is it to keep API compatibility (no need for ABI)?

It is an effort, and has roughly no benefit.  BFD is an integral part
of the tools that use it, not a clearly separated component.

-- 
Daniel Jacobowitz
CodeSourcery

Re: backward/forward compatibility of binutils

[Mikhail Teterin]

On Friday 07 July 2006 11:11, Daniel Jacobowitz wrote:
= It is an effort, and has roughly no benefit.

The benefits were mentioned even in this thread already -- to allow the same 
instance of bfd to be shared by multiple tools on a system. This is not just 
disk space, but also run-time memory consumption, tools build times, and ease 
and modularity of upgrading.

= BFD is an integral part of the tools that use it, not a clearly separated
= component.

Same is true for all "3rd party" libraries out there -- PNG, JPEG, TIFF, 
XML/EXPAT, LIBWWW -- you name it. All of them are only meaningful as parts of 
the applications that use them, and are equally clearly separated from them.

Yet _their_ authors are careful about API (and even ABI) compatibility -- and 
they are right.

I've been maintaining FreeBSD ports of 3rd-party software for years -- it is 
very annoying, when an application bundles its own version of a well-known 
and widely used package -- you are facing the wasted space, memory, 
bandwidth, and potential conflicts with the already installed versions.

Unfortunately, GNU toolchains and debuggers are like that, because keeping API 
compatibility is judged as "too much effort" by binutils developers...

	-mi

Re: backward/forward compatibility of binutils

[Ian Lance Taylor]

Mikhail Teterin <mi+kde@aldan.algebra.com> writes:

> Unfortunately, GNU toolchains and debuggers are like that, because keeping API 
> compatibility is judged as "too much effort" by binutils developers...

Would it be possible to implement BFD backward compatibility?  Yes.

Would it be hard?  Yes.  It is much harder than you think.  Analogies
to libraries like PNG are meaningless, because those libraries were
designed to be libraries, with a clearly defined API, to be used by
arbitrary third-party programs.  BFD was not designed to be a library;
it was designed to be a place to put the common routines shared by
GDB, gas, and the binutils.  It never intended to be used by
third-party programs (although, yes, a few people have managed it over
the years).

If you want to make it happen, then lay out a plan for how to get from
here to there, get buyin from the binutils developers, and then
implement it.

Don't expect it to happen by asking on this mailing list.  It will not
solve any problem faced by the binutils developers.  Instead, it will
require a great deal of extra work.  So just asking us to implement it
will accomplish nothing.

Ian

RE: backward/forward compatibility of binutils

[Dave Korn]

On 07 July 2006 15:44, Mikhail Teterin wrote:

> On Friday 07 July 2006 09:27, Jan-Benedict Glaw wrote:
> = Of course. I didn't mention that it would be a nice thing to have. I'm
> = actually opposed to it.
> 
> Why not? How hard is it to keep API compatibility (no need for ABI)?

  Fairly.  If it was trivial, it would be that way already!

>  Why do you insist on every tool bundling its own version?

  Well, how about "Because if you bork your system shared libs, and you badly
need a get-out-of-jail-free card, having statically linked executables in your
toolchain may well save your life." ?

  The toolchain binaries are so vital to the system that they should carry on
working no matter what else goes wrong.  For me, that's well worth the
overhead of a bit of disk space.  YMMV of course.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: backward/forward compatibility of binutils

[Mikhail Teterin]

On Friday 07 July 2006 11:40, Dave Korn wrote:
= > Why not? How hard is it to keep API compatibility (no need for ABI)?
= 
= б  Fairly. б If it was trivial, it would be that way already!

More difficult, than for the PNG, EXPAT, or TCL maintainers, for example? I 
know, it is not "trivial", but let's not exclude the middle of "possible, I 
guess" :-)

= > б Why do you insist on every tool bundling its own version?
= 
= б  Well, how about "Because if you bork your system shared libs, and you
= badly need a get-out-of-jail-free card, having statically linked executables
= in your toolchain may well save your life." ?

This is a reason to keep the native tool-chain executables linked statically 
(as well as make, and whatever else is needed to rebuild the shared libs).

This is NOT a reason for each tool bundling its own version... There is not 
one, I think...

A complete, compatible, centrally installed (with headers and both static and 
shared libraries) version of bfd would also allow make installing various 
cross-compilers and cross-debuggers easier, and allow disassembling foreign 
binaries, and analyzing foreign cores.

The linkage mode (such as static for the native cc, ld, as and shared for gdb 
and the non-native tools) can then be decided upon by those, who 
build/package each tool for the system -- I believe, this is addresses your 
point (viz. "get-out-of-jail-free card").

A new version of, say, gdb would not need to include its own bfd anymore -- it 
could simply require one to be present on the system and to be at a certain 
version or higher. Whether or not it ends up linking with it statically is a 
different issue altogether, actually...

Still unsure?

	-mi

Re: backward/forward compatibility of binutils

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Fri, 2006-07-07 12:15:32 -0400, Mikhail Teterin <mi+kde@aldan.algebra.com> wrote:
> On Friday 07 July 2006 11:40, Dave Korn wrote:
> = > Why not? How hard is it to keep API compatibility (no need for ABI)?
> = 
> =   Fairly.  If it was trivial, it would be that way already!
> 
> More difficult, than for the PNG, EXPAT, or TCL maintainers, for example? I 
> know, it is not "trivial", but let's not exclude the middle of "possible, I 
> guess" :-)

For sure, yes. Just look at binutils and its users. Every now and
then, there's an extension to some processor architecture imposing new
defines etc. Each time, you have to increase the version number of the
libbfd. That way, if you install binutils and gdb at two times, you're
likely ending up with one lib for each, as well as two sets of header
files.

For eg. file parsing libraries like PNG, there's not much that changes
in the PNG standard over the time. For processors and their features,
a lot changes. All the time.

> This is a reason to keep the native tool-chain executables linked statically 
> (as well as make, and whatever else is needed to rebuild the shared libs).
> 
> This is NOT a reason for each tool bundling its own version... There is not 
> one, I think...

Actually, there isn't one version for each tool. Don't only have a
look at the released tarballs, but also at the CVS server. You'll find
out that there's only one libbfd.

> A complete, compatible, centrally installed (with headers and both static and 
> shared libraries) version of bfd would also allow make installing various 
> cross-compilers and cross-debuggers easier, and allow disassembling foreign 
> binaries, and analyzing foreign cores.

Forget that, quickly.  If you install one set of toolchains, once, you
get away with that.  But if you follow development where CPU features
are added all the time, you likely end up with a dozend installations
of libbfd, along with header files.

> A new version of, say, gdb would not need to include its own bfd anymore -- it 
> could simply require one to be present on the system and to be at a certain 
> version or higher. Whether or not it ends up linking with it statically is a 
> different issue altogether, actually...

You will probably face quite a hard time linking different snapshots
of objdump, gdb, readelf etc. with one single libbfd. Every time new
features are included (or existing features are changed), all
components in the `src' CVS repository will be touched. That just
won't work.

> Still unsure?

Yap.  Conceptionally, there is no such thing like a "stand-alone,
feature-complete libbfd". It's highly interwoven with the tools, and
both will be adopted matching each other whenever a change is needed.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: backward/forward compatibility of binutils

[Dave Korn]

On 07 July 2006 17:31, Jan-Benedict Glaw wrote:
> On Fri, 2006-07-07 12:15:32 -0400, Mikhail Teterin
>> On Friday 07 July 2006 11:40, Dave Korn wrote:
>> = > Why not? How hard is it to keep API compatibility (no need for ABI)? =
>> =   Fairly.  If it was trivial, it would be that way already!
>> 
>> More difficult, than for the PNG, EXPAT, or TCL maintainers, for example? I
>> know, it is not "trivial", but let's not exclude the middle of "possible, I
>> guess" :-)
> 
> For sure, yes. Just look at binutils and its users. Every now and
> then, there's an extension to some processor architecture imposing new
> defines etc. Each time, you have to increase the version number of the
> libbfd. That way, if you install binutils and gdb at two times, you're
> likely ending up with one lib for each, as well as two sets of header
> files.
> 
> For eg. file parsing libraries like PNG, there's not much that changes
> in the PNG standard over the time. For processors and their features,
> a lot changes. All the time.

  And consider the scale of the changes between Dwarf-2 and Dwarf-3.  Any old libbfd that was written before Dwarf-3 could never have anticipated and provided extensibility for all those new features.

>> A new version of, say, gdb would not need to include its own bfd anymore
>> -- it could simply require one to be present on the system and to be at a
>> certain version or higher. Whether or not it ends up linking with it
>> statically is a different issue altogether, actually...
> 
> You will probably face quite a hard time linking different snapshots
> of objdump, gdb, readelf etc. with one single libbfd. Every time new
> features are included (or existing features are changed), all
> components in the `src' CVS repository will be touched. That just
> won't work.
> 
>> Still unsure?
> 
> Yap.  Conceptionally, there is no such thing like a "stand-alone,
> feature-complete libbfd". It's highly interwoven with the tools, and
> both will be adopted matching each other whenever a change is needed.


  Yes, this is at the crux of it.  Gdb, for example, is highly tied to the debugging data format.  Although gdb could *in theory* be rewritten to examine the libbfd, find out what version you have, deduce which features it supports and which it doesn't, it would take a VAST amount of work, which would quickly become out-of-date.  Much better for gdb to be tied to bfd, so that it 'just knows' what features are supported and which aren't.  After all, wouldn't people be disappointed if they downloaded and installed a new gdb and it *still* didn't come with the latest features (like Dwarf-3 parsing) because they had to change their system libbfd as well?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: backward/forward compatibility of binutils

[Mikhail Teterin]

ц░'ц▒ц■ц▌ц┴ц┐ц▒ 07 ц▄ц┴ц░ц┘ц▌ц≤ 2006 12:30, Jan-Benedict Glaw ц▌ц│ц░ц┴ц⌠ц│ц≈:
> Forget that, quickly.  If you install one set of toolchains, once, you
> get away with that.  But if you follow development where CPU features
> are added all the time, you likely end up with a dozend installations
> of libbfd, along with header files.

Why would I end up with "dozens installations", instead of one, that's the 
most recent?

If the API compatibility is accepted as desired (which is what I'm trying to 
achieve), it will be possible to recompile the older versions of the tools 
against the new bfd's headers -- with minimum, if any, effort...

I may sound arrogant, but I don't see, how the bfd is different from, again, 
JPEG or PNG -- it provides a way to deal with different binary formats, not 
entirely unlike the different image formats (there are many kinds of PNGs 
too, BTW).

Things are, of course, trickier, when the tools have to deal with live 
processes (and kernels), but those areas are tiny and require a great deal of 
OS/arch level customization anyway...

> Conceptionally, there is no such thing like a "stand-alone,
> feature-complete libbfd".

Sorry for the confusion -- I did not mean "feature-complete". By "complete" I 
meant, that support for all formats known at the compile time is compiled in.

> It's highly interwoven with the tools, and both will be adopted matching
> each other whenever a change is needed. 

So, there is no one straightforward development trunk (with minimally 
incompatible branches), but a whole bush of versions, which are slightly 
incompatible with each other? This appears to have been the case some years 
ago, and I am saddened, that it remains so...

ц░'ц▒ц■ц▌ц┴ц┐ц▒ 07 ц▄ц┴ц░ц┘ц▌ц≤ 2006 13:25, Ian Lance Taylor ц▌ц│ц░ц┴ц⌠ц│ц≈:
> Don't expect it to happen by asking on this mailing list.  It will not
> solve any problem faced by the binutils developers.  Instead, it will
> require a great deal of extra work.  So just asking us to implement it
> will accomplish nothing.

So far, I can't even get an agreement, that it would be a good thing! Even if 
I did all of this "great deal of extra work", it would still be rejected...

On the other hand, if/when this agreement is reached, the actual amount of 
work would not be so huge -- there is little (if anything) to REDO. Just keep 
the desirability of backwards compatibility in mind _going forward_.

Yours,

	-mi

Re: backward/forward compatibility of binutils

['Daniel Jacobowitz']

On Fri, Jul 07, 2006 at 02:41:12PM -0400, Mikhail Teterin wrote:
> I may sound arrogant, but I don't see, how the bfd is different from, again, 
> JPEG or PNG -- it provides a way to deal with different binary formats, not 
> entirely unlike the different image formats (there are many kinds of PNGs 
> too, BTW).

Sorry, but please stop discussing this on the list.  Ian's response is
definitive.  It answers most of your questions from this message.

> Things are, of course, trickier, when the tools have to deal with live 
> processes (and kernels), but those areas are tiny and require a great deal of 
> OS/arch level customization anyway...

BFD has nothing to do with that anyway.

-- 
Daniel Jacobowitz
CodeSourcery

Re: backward/forward compatibility of binutils

[Mikhail Teterin]

ц░'ц▒ц■ц▌ц┴ц┐ц▒ 07 ц▄ц┴ц░ц┘ц▌ц≤ 2006 14:45, 'Daniel Jacobowitz' ц▌ц│ц░ц┴ц⌠ц│ц≈:
> Sorry, but please stop discussing this on the list. б Ian's response is
> definitive. б It answers most of your questions from this message.

Ian's response is: "Do it yourself". There is not much to do, besides 
agreeing, that the compatibility would be a desirable goal...

I guess, I'll ask again a few years later. Maybe, some newer blood will 
improve things (including manners) by then...

Have a good weekend.

	-mi

Re: backward/forward compatibility of binutils

['Daniel Jacobowitz']

On Fri, Jul 07, 2006 at 02:56:14PM -0400, Mikhail Teterin wrote:
> Ian's response is: "Do it yourself". There is not much to do, besides 
> agreeing, that the compatibility would be a desirable goal...

You've missed his entire point, which is that the current interface is
not designed extensibly.  It would be a great deal of work to preserve
it in the face of major changes - work which no one who would be making
those changes has interest in doing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: backward/forward compatibility of binutils

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 5233 bytes --]

On Fri, 2006-07-07 14:41:12 -0400, Mikhail Teterin <mi+mx@aldan.algebra.com> wrote:
> п'ятниця 07 липень 2006 12:30, Jan-Benedict Glaw написав:
> > Forget that, quickly.  If you install one set of toolchains, once, you
> > get away with that.  But if you follow development where CPU features
> > are added all the time, you likely end up with a dozend installations
> > of libbfd, along with header files.
> 
> Why would I end up with "dozens installations", instead of one, that's the 
> most recent?
> 
> If the API compatibility is accepted as desired (which is what I'm trying to 
> achieve), it will be possible to recompile the older versions of the tools 
> against the new bfd's headers -- with minimum, if any, effort...

As long as the library version is correct, right.  But right now,
every now and then, there's an incompatible change and nobody cares to
think long about it.

> I may sound arrogant, but I don't see, how the bfd is different from, again, 
> JPEG or PNG -- it provides a way to deal with different binary formats, not 
> entirely unlike the different image formats (there are many kinds of PNGs 
> too, BTW).

How often do you see a change in the format of a JPEG picture, for
example? Right, there've been some five or six changes over the time.

How often do you see new processor architectures, new architectural
features or simply new ABIs come up? That's more like a weekly
business.

Sometimes, these are even exclusive, so the callee better knows about
that. You could implement a number of feature-checking functions to
libbfd, and call these from all callers, but is this worth it?

> > Conceptionally, there is no such thing like a "stand-alone,
> > feature-complete libbfd".
> 
> Sorry for the confusion -- I did not mean "feature-complete". By "complete" I 
> meant, that support for all formats known at the compile time is compiled in.

You can, of course, take any libbfd snapshot. But after all, it's just
a random collection of functions. There's no strict interface or API
for it, that's why it's different compared to other libs, like libjpeg
and the like.

> > It's highly interwoven with the tools, and both will be adopted matching
> > each other whenever a change is needed. 
> 
> So, there is no one straightforward development trunk (with minimally 
> incompatible branches), but a whole bush of versions, which are slightly 
> incompatible with each other? This appears to have been the case some years 
> ago, and I am saddened, that it remains so...

In the trunk of the CVS repository, there's the Latest and Greatest
version, as well as properly hacked binutils/gdb/... to use this.
There are branches, but from my point of view, the trunk is most
important. And for trunk, you're better off taking every post-commit
state as a completely unrelated and new _version_ of the whole set of
tools.

If there's a good reason to move functions around or change them,
they'll just be changed, along with their callers.

> п'ятниця 07 липень 2006 13:25, Ian Lance Taylor написав:
> > Don't expect it to happen by asking on this mailing list.  It will not
> > solve any problem faced by the binutils developers.  Instead, it will
> > require a great deal of extra work.  So just asking us to implement it
> > will accomplish nothing.
> 
> So far, I can't even get an agreement, that it would be a good thing! Even if 
> I did all of this "great deal of extra work", it would still be rejected...

It will be accepted in the sole case that defining a definitive API
for libbfd doesn't make it harder to freely move code around and
change it.  Remember, its current state is "highly interwoven",
instead of "a clearly separate work."

> On the other hand, if/when this agreement is reached, the actual amount of 
> work would not be so huge -- there is little (if anything) to REDO. Just keep 
> the desirability of backwards compatibility in mind _going forward_.

Who'll implement backward compatibility code? ...or alternatively
increase the library version number?

Does compatibility code add bloat to the lib? Is there an easy way to
exclude it from a compilation run?

Do all the binutils and gdb need extra code (or configury) to get the
currently installed libbfd's configuration? Who'll write that? Does it
add bloat to the binutils/gdb codebase? Can this be excluded for a
compilation run?

I guess these are the main questions to answer. Just to cut a long
story short, I am a user of a "standalone" libbfd which I'm using for
disassembling. Initially I also thought that a fixed API would help me
(to not need to change my program every now and then, which I
definitively needed to do!), but I just realized that making a real
lib out of it is just a horrid hard piece of fruitless work.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: backward/forward compatibility of binutils

[Mikhail Teterin]

ц░'ц▒ц■ц▌ц┴ц┐ц▒ 07 ц▄ц┴ц░ц┘ц▌ц≤ 2006 15:02, Jan-Benedict Glaw ц▌ц│ц░ц┴ц⌠ц│ц≈:
> > If the API compatibility is accepted as desired (which is what I'm trying
> > to achieve), it will be possible to recompile the older versions of the
> > tools against the new bfd's headers -- with minimum, if any, effort...
>
> As long as the library version is correct, right.  But right now,
> every now and then, there's an incompatible change and nobody cares to
> think long about it.

This "nobody cares to think long about" part is exactly what I'd like changed.

> > I may sound arrogant, but I don't see, how the bfd is different from,
> > again, JPEG or PNG -- it provides a way to deal with different binary
> > formats, not entirely unlike the different image formats (there are many
> > kinds of PNGs too, BTW).
>
> How often do you see a change in the format of a JPEG picture, for
> example? Right, there've been some five or six changes over the time.
>
> How often do you see new processor architectures, new architectural
> features or simply new ABIs come up? That's more like a weekly
> business.

These don't require abandoning the existing architectures/ABIs weekly. (And 
frankly, I'm unconvinced of the bfd's super-fluid mobility. Windows/x64 has 
been around for years now, but is still not supported, for example...)

> Sometimes, these are even exclusive, so the callee better knows about
> that. You could implement a number of feature-checking functions to
> libbfd, and call these from all callers, but is this worth it?

I don't see ImageMagick unduly suffering from the quickly evolving png, jpeg, 
tiff, jasper, mng, jbig, freetype, fontconfig, and Perl.

For another example, we have not seen any trouble ever since the FreeBSD ports 
of Mozilla-derived browsers switched to using the centrally-built (and 
tightly tested!) nspr and nss modules.

> I guess these are the main questions to answer. Just to cut a long
> story short, I am a user of a "standalone" libbfd which I'm using for
> disassembling. Initially I also thought that a fixed API would help me
> (to not need to change my program every now and then, which I
> definitively needed to do!), 

Having to change a program to work with the most recent release of bfd is fine 
and acceptable. What is not acceptable is having a bunch of different bfds, 
which all require different changes...

Unfortunately, your experience confirms that of the FreeBSD developers, who 
tried to centralize the binutils libraries in one location, and gave up 
(although, NetBSD, I think, succeeded in some shape or form).

> but I just realized that making a real lib out of it is just a horrid hard
> piece of fruitless work.

Poor initial design, no one willing to fix it (and even some scorn poured at 
the outsiders advocating improvement). All of the implorations of CS 
professors have been in vain...

	-mi

Re: backward/forward compatibility of binutils

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

On Fri, 2006-07-07 15:46:17 -0400, Mikhail Teterin <mi+mx@aldan.algebra.com> wrote:
> п'ятниця 07 липень 2006 15:02, Jan-Benedict Glaw написав:
> > How often do you see a change in the format of a JPEG picture, for
> > example? Right, there've been some five or six changes over the time.
> >
> > How often do you see new processor architectures, new architectural
> > features or simply new ABIs come up? That's more like a weekly
> > business.
> 
> These don't require abandoning the existing architectures/ABIs weekly. (And 
> frankly, I'm unconvinced of the bfd's super-fluid mobility. Windows/x64 has 
> been around for years now, but is still not supported, for example...)

Look for changes in eg. the MIPS code.

...and a system not being supported only states one single fact:
Nobody cared enough about that system to implement whatever needs to
get implemented.

Compare to: Some months ago, some guy found a teeeny bug in the PDP11
code. There were two independant (and equal) fixes for this issue
within a day or two.

> > Sometimes, these are even exclusive, so the callee better knows about
> > that. You could implement a number of feature-checking functions to
> > libbfd, and call these from all callers, but is this worth it?
> 
> I don't see ImageMagick unduly suffering from the quickly evolving png, jpeg, 
> tiff, jasper, mng, jbig, freetype, fontconfig, and Perl.

When was the last change to these formats that also affected the
implementation of older versions?

Keeping a stable version is _easy_ if you only extend functionality,
but not, if functionality _changes_.

> For another example, we have not seen any trouble ever since the FreeBSD ports 
> of Mozilla-derived browsers switched to using the centrally-built (and 
> tightly tested!) nspr and nss modules.

These have a well-defined interface. libbdf doesn't have that. It's
just a random collection of functions.

> > I guess these are the main questions to answer. Just to cut a long
> > story short, I am a user of a "standalone" libbfd which I'm using for
> > disassembling. Initially I also thought that a fixed API would help me
> > (to not need to change my program every now and then, which I
> > definitively needed to do!), 
> 
> Having to change a program to work with the most recent release of bfd is fine 
> and acceptable. What is not acceptable is having a bunch of different bfds, 
> which all require different changes...

This is why there's one trunk version.

> > but I just realized that making a real lib out of it is just a horrid hard
> > piece of fruitless work.
> 
> Poor initial design, no one willing to fix it (and even some scorn poured at 
> the outsiders advocating improvement). All of the implorations of CS 
> professors have been in vain...

Yap, that's a possibly valid point of view. But unless patches (with
copyright assignments in place) show up, nothing will change.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: backward/forward compatibility of binutils

[Christopher Faylor]

On Fri, Jul 07, 2006 at 03:46:17PM -0400, Mikhail Teterin wrote:
>Poor initial design, no one willing to fix it (and even some scorn poured at 
>the outsiders advocating improvement). All of the implorations of CS 
>professors have been in vain...

Yeah, it's either that or the "outsider" doesn't quite understand the
issues, how open source development works, or both.

cgf

Re: backward/forward compatibility of binutils

[Ian Lance Taylor]

Mikhail Teterin <mi+mx@aldan.algebra.com> writes:

> Poor initial design, no one willing to fix it (and even some scorn poured at 
> the outsiders advocating improvement). All of the implorations of CS 
> professors have been in vain...

OK, you got us.  You're absolutely right.

I think we've gone far enough on this thread.  If you want to pursue
this, please drop this for now and come back with your redesigned API
for libbfd which can be used going forward.  Pay close attention to
the complex interaction between libbfd and ld.

Please don't expect us to design that API: we don't care.  Please
don't tell us that we can freeze on the current API: we know better.

Ian