backward/forward compatibility of binutils

[Jan-Benedict Glaw]

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));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20060707/bfa00f29/attachment.sig>