On Fri, Jul 28, 2017 at 03:06:29PM +0200, Florian Weimer wrote: > 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: > > <https://sourceware.org/ml/libc-alpha/2017-07/msg00968.html> > > 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. I think it is seriously flawed optimization that should be at least turned off by default. If people are willing to do this mess on ppc64le for some libraries, they should request it explicitly, but we certainly shouldn't make the implementation details part of exported ABI for all shared libraries. Then the ABI depends even on compiler flags used to compile the routines etc., you recompile with -O0 and suddenly you've changed ABI. Furthermore, how does it work with symbol interposition? Say if malloc happened to not clobber/use r2 and does not use r12, you suddenly couldn't use ElectricFence or valgrind or AddressSanitizer where the implementation would need to do that. Can the decision if this braindamange should be used or not be done on a per-shared library basis, then it might be useful for shared libraries solely used by binaries in the same package where nothing else uses them. But otherwise, just say no to this. Ugh. Jakub _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
