Re: Can objdump show friendly symbolic function name?

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Tue, 20 Jul 2010, David Daney wrote:

> >   Support for large GOT has been defined since the beginning of the MIPS
> > ELF ABI (GOTHI16/GOTLO16 relocations etc.), but I have been told it
> > requires all the dependent libraries (down to libc) to be rebuilt (never
> > analysed that myself), at which point you have to rebuild the whole system
> > or create another set of multilibs.  Given a large GOT has a considerable
> > performance hit, it does not sound like a good idea to make all the
> > programs in a system suffer to serve the few offenders.
> 
> That is not the case.
> 
> Case in point (before multi-got bugs were fixed), I had reliably working on
> mipsel-linux (o32):
> 
> Application: no -mxgot
> libc.so.6/libpthread.so.???: no -mxgot
> other .so files: no -mxgot.
> libgcj.so.???: -mxgot.
> 
> 
> As far as I know, you can mix -mxgot and non -mxgot executables and shared
> objects.

 So what was the fuss about when Mozilla (or whatever monstrous program 
that was) failed to compile with standard GOT one day then?  Why didn't 
they simply build whatever the failing object was with -mxgot and the 
multi-GOT scheme was added to binutils instead?  It looks to me like an 
overkill solution was chosen, so surely there must have been a reason.

> > > It might be nice to add a function attribute that lets us turn -mxgot on
> > > and
> > > off on a per function basis, instead of the current per compilation unit
> > > basis
> > > of today.
> > 
> >   As I say the biggest concern are whole programs and not single functions.
> > Feel free to implement large GOT support such that mixing objects or even
> > single functions in a link is possible.  How would you determine which
> > function to annotate with the attribute -- manually by trial and error?
> > It doesn't seem that would scale well to me.  We've been through it with
> > the -G option.
> > 
> 
> -G does complicate things, but IIRC Linux userspace ABIs all have -G 0, so
> there is no small data.  Of course for systems with small data you would have
> to consider this.

 I don't mean any -G (re)consideration for Linux or any other environment.

   What I have in mind is determining manually which functions to select 
for large GOT annotation (and remove afterwards as the program in question 
evolves) is as (non-)trivial as selecting the right -G option where it 
applies.  The same goes for grouping local-scope functions most frequently 
calling one another together so that BAL can be used instead of the slower 
JALR that doesn't play well with the branch predictor, etc.

 Any such kind of stuff that has to be done manually is inefficient, 
error-prone and best avoided.

  Maciej