https://bugzilla.redhat.com/show_bug.cgi?id=1064271 --- Comment #33 from Andreas Krebbel <krebbel1@xxxxxxxxxx> --- (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). 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. 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 -- 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=UcrnZIPsBD&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
