[PATCH 00/20] Create and use hidden aliases in libgmp.so
tg at gmplib.org
Mon Mar 4 21:21:46 CET 2013
Richard Henderson <rth at twiddle.net> writes:
This does not adjust the public interface at all, or tidy the
internal namespace at all. What it does do is annotate the source
(in as few places as possible) so that we automatically create and
use the hidden internal aliases inside the library, while still
exporting the same external symbols.
Thanks a bunch for this big work!
What sort of paperwork do you and Red hat have in place? We need to
extend it as soon as possible, if the current paperwork needs amending.
(Last time, for David Miller, it took something like two months, and
only after some nagging.)
The results are easy to see:
$ readelf -r libgmp.so-old | grep section
Relocation section '.rela.dyn' at offset 0x8148 contains 108 entries:
Relocation section '.rela.plt' at offset 0x8b68 contains 344 entries:
$ readelf -r libgmp.so-new | grep section
Relocation section '.rela.dyn' at offset 0x7fc0 contains 83 entries:
Relocation section '.rela.plt' at offset 0x8788 contains 31 entries:
and all of the plt entries are into libc.
For the static library, and if hidden aliases are not supported, we
don't do any hidden alias trickery, but do attempt to use GCC's asm
extension to give the source-level symbols the linkage symbols that
we desire, without resorting to extra preprocessor macros. This
ought to improve the debugging experiance.
And as a last resort, we fall all the way back to preprocessor macros.
But this time they're machine generated instead of obscuring the source
by maintaining all those names by hand.
I've tried to do this in a series of steps that are as mechanical as
possible, and therefore as easy to review as possible.
Is the patch set intended to be applied as a whole, or will applying
each (in number order) give something which is intended to work.
I'm no m4 guru, so there may be a better way to handle the changes to
asm-defs.m4. Although I'm frankly a bit confused as to why we're using
m4 for the assembly macro-isation, as opposed to the C preprocessor.
Because we need the power of m4. Not everywhere, but in some files. We
used cpp a long time ago (and still do for 2 assembly files) instead of
In particular, when -g is passed through from gcc to gas, gas sees and
records the # file line markers that the preprocessor leaves, and puts
that into the auto-generated line number debugging info. With our m4
scheme we get no such # markers and instead gas records line number
info assocated with a no longer extant temp file. Not really helpful.
There's probably some way to address this one problem, for a m4 guru.
I don't see any problem which needs addressing. I am perfectly happy
with how debugging works with the asm code now.
But perhaps more importantly, everyone who programs in C understands
how the preprocessor works. But the pool of m4 hackers is much smaller.
There are hidden pitfalls like cpp self defines being ok, while m4 self
defines lead to stack overflow.
You can do many things in m4 which I don't know how to handle in cpp.
E.g., for x86 and PIC, we need to remember a list of thunks to output at
More information about the gmp-devel