[PATCH 00/20] Create and use hidden aliases in libgmp.so

[Torbjorn Granlund]

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.
  
Cool.

  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
m4.

  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
the end.

-- 
Torbjörn