https://bugzilla.redhat.com/show_bug.cgi?id=1064271
--- Comment #35 from Carlos O'Donell <codon...@redhat.com> --- Andreas, I've written up "Packaging Changes" notes for this in upstream: https://sourceware.org/glibc/wiki/Release/2.19#Packaging_Changes Could you please checkin a note to the 2.19 section of the NEWS file in upstream stating that there is an ABI even for s390/s390x, please also could you backport that to the active 2.19 branch (requires Allan McRae to sign off). This way we've covered our bases and made it clear in NEWS and release notes that there is a potential ABI issue coming down the pipe. I will work within Red Hat to get this information to all of our customers. (In reply to Andreas Krebbel from comment #33) > (In reply to Carlos O'Donell from comment #32) > > All of this could have been handled by using the compiler to generate a > > .gnu.attribute entry for the new ABI when such a structure was used. Then > > the static linker could generate a warning when linking mixed ABI objects > > (undefined + new ABI) or an error (old ABI + new ABI). This results in a > > much better user experience and the .gnu.attributes track which ABI > > components are in use (look at ARM which tracks the size of wchar_t). > > So far this has been used solely for indicating ABI relevant changes > inflicted by compiler options. What you propose would be the first use for > changes of Glibc data structures. It probably requires some more work to > either > detect all usages of such data structures and compare their definitions > within GCC to emit the proper flags > - or - > to provide a language level type attribute to put an abi tag on data > structures which is then translated by GCC to the .gnu.attr... stuff (after > tracking down all its embedded uses). That is correct. Nobody wants to be the first to attempt this :-) Worse is that this only works when building your application. At runtime if the library is updated you need to use an ELF header flag (e_flag) bit or 2 bits to annotate the ABI change and this allows ldconfig to correctly discover and handle allowing old binaries to load new modules with the new ABI. Note that this is ABI markup at the object file level for runtime diagnostics, but we really want that data to live at the function and and variable and trickle up. Keeping the ABI markup at the function level for the runtime is probably too costly. Imagine the dynamic loader comparing function ABIs as it resolves PLT entries! > While I think that mechanism would have been useful for static linking the > situation with dynamic linking and Glibc data structures is a bit better > since we have the accessor functions under control. Of course there might be > somebody directly accessing a jmpbuf but that's hopefully a very rare case. > Due to the symbol versioning of the accessor functions there are only few > cases left where this is actually a problem. In general you can dynamically > link two objects using different jmpbuf versions. They would use different > sets of setjmp/longjmp symbols in glibc and all should be fine. Problems > only occur if they pass jmpbuf objects to each other. So the mechanism above > would trigger in too many cases to be useful I think. That is correct, but this issue shows that it's actually common to run into these problems changing the size of any of the structures exported for public use by glibc. Fixing the accessor macros never works perfectly. Too many applications simply embedded the jmpbuf direclty into another structure and that is eventually used by newer compiled object code which expects the new size and it fails. I expect Ruby is going to fail also since it embeds jmp_buf similarly. > Note: In fact even passing jmpbufs between .so's isn't a problem currently > since the reserved fields are never accessed. The only problem we have right > now is if: > 1. a jmpbuf is embedded in another data structure (not being the last > element) > 2. that data structure is shared among modules assuming different jmpbuf > sizes That is correct. Unfortunately this is much more common than you think. Either way, if we need to extend jmp_buf and struct ucontext we need to do it. Our primary goals should be: * Clear communication to our customers of both the benefits and the problems. * Better diagnostics for mixing code that could result in an ABI breakage. I think we can and should be doing better on that second bullet point. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=eAzubGxNjt&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
