Bug#888073: glibc: Support amd64 systems without /lib64

[Michael Matz <matz@suse.de>]

Hi,

On Mon, 29 Jan 2018, Javier Serrano Polo wrote:

> El dl 29 de 01 de 2018 a les 13:43 +0000, Michael Matz va escriure:
> > To see why that is so suppose I'm changing my compiler to use a different 
> > calling convention in which the first argument is passed in %rsi and the 
> > second in %rdi, and otherwise it's all the same.
> 
> Could you tell me why on earth would you want to do that? Is there any 
> speed advantage?

No, of course not.  It was an easy to understand change to demonstrate a 
point I was trying to make.  Obviously I failed.  If I had known that 
you'd be triggered by the senselessness of the proposal I'd have made a 
different one: making some of the floating point regs be callee saved, 
which indeed would help benchmarks quite some.  The way it's now 
(everything caller saved) is actually an artifact of the first 
implementations of the x86-64 insn set, and in retrospect was not the best 
choice.  We _still_ won't make a change like that, even though it'd have a 
comparatively large advantage.

> You are comparing a function-calling convention with a 
> filesystem requirement.

No, I compared an ABI change with an ABI change.

> There is an interest in dropping /lib64 and 
> maintain interoperability, and I find it legitimate.

Dropping /lib64 basically means dropping interoperability.

> > I recompile my whole system and I adjust all the various assembler 
> > snippets that have it hard-coded.
> 
> Yet another person that believes I must recompile my whole system.
> 
> > Does it make 
> > sense to encode this new calling convention in the psABI?
> 
> Give me the reason for the new calling convention and I will tell you
> whether it makes sense.

You realized that this was a rhethoric question, right?  I assume so from 
you removing my "No.", so what's your point?

> > So, while you might say that putting the loader into an alternative path 
> > is a maintainers choice, it's a (badly advised) maintainers choice of not 
> > following the psABI, not a good reason to change it.
> 
> Cleaner filesystem and multiarch simplicity. We have different views of
> what constitutes good advice.

Obviously.

> > So, no, we can't change the psABI in that respect without 
> > repercussions for all systems claiming to be conforming, which is a 
> > bad idea for an ABI that's already nearly 20 years old.
> 
> Sorry, I thought "Draft Version" meant to be a draft.

Is does, but draft means many things, and for the psABI doesn't include 
"making backward incompatible changes is okay".

> Also, I must have misunderstood the following:
> 
>         The System V Application Binary Interface will evolve over time
>         to address new technology and market requirements, and will be
>         reissued at intervals of approximately three years. Each new
>         edition of the specification is likely to contain extensions and
>         additions that will increase the potential capabilities of
>         applications that are written to conform to the ABI.

Indeed.  We should probably remove this paragraph.

> The only repercussion you are talking about is that systems will not be 
> able to make a claim if they do not adapt to the new version. There are 
> no real interoperability issues, as my previous counterexample proves.

You gave no counterexamples.  You explained the interop problems away by 
stating that "non-evolving" systems merely need to not claim compatibility 
with the newest version and all will be fine.

> I guess it is too much for distros to ship a symlink that would help 
> Debian-based systems to get rid of /lib64.

Yes, it is.  We basically need to make a choice between two things:
(a) change the psABI -> debian can get rid of /lib64 (but see below), 
    everybody else needs to add the new loader name (at least if they want 
    to "evolve"), or
(b) don't change the psABI -> no changes anywhere

A change in an psABI necessarily needs to have a very high barrier to 
entry, so it needs to have some very sound and large advantages.  Let's 
look at the advantage of (a): debian can get rid of a filename (and 
possibly directory), everybody else needs to add a filename.  Even that 
doesn't sound like a very large advantage considering everything.  But 
debian can't _actually_ get rid of the dir and filename, because not all 
software is compiled on debian, so 3rd party software conceivably would 
continue to use the current loader name.  In the name of cleanliness you 
probably would move that "old" loader name into some new subpackage of 
glibc so that you only need it when such 3rd party apps are actually 
installed.  But still you wouldn't be able to get rid of it wholly.  
So now you've made an ABI change that resulted in adding a name for 
everybody, plus a new subpackage.  Even less an advantage.  You also 
create confusion (if not about anything else, then at least about which 
ABI versions a system is conforming to), which is something that 
absolutely must be avoided in an ABI.

What exactly is the reason why you want to change the ABI?  Beauty of 
filesystem layout?  If so, then I'm sympathizing but I fear you'll have to 
live with uglyness (or, of course, just not be psABI compliant on that 
point).  "The thing will be nicer this way" is never a good reason to 
change anything in an existing psABI.


Ciao,
Michael.