X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, a...@suse.de
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? You are comparing a function-calling convention with a
filesystem requirement. There is an interest in dropping /lib64 and
maintain interoperability, and I find it legitimate.
> 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.
> A psABI-compliant system then
> suddenly wouldn't only have to provide /lib64/ld-linux-x86-64.so.2, but
> also your proposed file; i.e. alternatives in an ABI are actually
> additional requirements on the system (they're alternatives only for a
> particular file). If a system wouldn't do that then it can't claim to be
> psABI-compatible anymore as there would exist executables which can't be
> loaded on it.
That happens with any standard. A system can be POSIX.1-2001 compliant
and not POSIX.1-2008 compliant; it does not support the new features. An
AMD64 system that does not evolve can always claim to be compatible with
version 0.99.7.
> 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.
> This is slightly different from the choice of not following the suggestion
> in the psABI of putting libraries into **/lib64, like the multiarch
> approach is doing.
Sorry for not CCing. You missed the bits about custom loaders and
DT_NEEDED.
> 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. 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.
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.
I guess it is too much for distros to ship a symlink that would help
Debian-based systems to get rid of /lib64.
smime.p7s
Description: S/MIME cryptographic signature
