On 07/28/2017 02:22 PM, Mark Wielaard wrote:
On Fri, 2017-07-28 at 13:39 +0200, Florian Weimer wrote:
> binutils 2.29 introduced an optimization which requires that in the
> general case, applications and libraries linking against a DSO will have
> to be rebuilt when the DSO change the implementation of functions (i.e.,
> changes to a function body can change ABI). This is how many native
> programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
> but it's a material change for C and C++.
> The question is: Do we want to move into that direction, or do we need
> to ask binutils upstream to back out this change?
Could you be a bit more specific? Normally that is why you use symbol
versioning isn't it? Does binutils now warn when it detects such an ABI
change? How does it know?
Conceptually, this optimization inlines aspects of the called function
into the caller, across DSO boundaries. In particular, as implemented
now on ppc64le, the net effect is that the ABI changes if you add a
global variable access to a function which previously did not have one.
I posted a more technical summary here:
It is theoretical possible to make this work with symbol versions, but
we don't have any tools for that right now.
Writing this message I realized that it's not worth to have a serious
discussion about this binutils change. It's just wrong and breaks ELF
dynamic linking. Sorry about the noise.