Can objdump show friendly symbolic function name?

Can objdump show friendly symbolic function name?

[Pan ruochen]

Hi All,

I am developing with mips-linux toolchain. I always need to do some
analysis on the disassembly code.
But objdump displays as following:
----------------------------------------------------------------------------------------
0001c370 <semget>:
   1c370:   3c1c0005    lui gp,0x5
   1c374:   279ce080    addiu   gp,gp,-8064
   1c378:   0399e021    addu    gp,gp,t9
   1c37c:   27bdffd8    addiu   sp,sp,-40
   1c380:   afbf0024    sw  ra,36(sp)
   1c384:   afbc0018    sw  gp,24(sp)
   1c388:   00a01021    move    v0,a1
   1c38c:   00c03821    move    a3,a2
   1c390:   00403021    move    a2,v0
   1c394:   8f828880    lw  v0,-30592(gp)
   1c398:   8f998204    lw  t9,-32252(gp)
   1c39c:   2403ffff    li  v1,-1
   1c3a0:   ac430000    sw  v1,0(v0)
   1c3a4:   00802821    move    a1,a0
   1c3a8:   afa00010    sw  zero,16(sp)
   1c3ac:   afa00014    sw  zero,20(sp)
   1c3b0:   0320f809    jalr    t9
   1c3b4:   24040002    li  a0,2
   1c3b8:   8fbf0024    lw  ra,36(sp)
   1c3bc:   8fbc0018    lw  gp,24(sp)
   1c3c0:   03e00008    jr  ra
   1c3c4:   27bd0028    addiu   sp,sp,40
----------------------------------------------------------------------------------------

It is really hard to read disassembly code like that since I can't see which
function is called from `jalr t9'.

Is there some way to inform objdump to display more friendly symbolic name
as following?

bfc020f8 <try_nand_flash_boot>:
bfc020f8:	27bdffe0 	addiu	sp,sp,-32
bfc020fc:	3c02b404 	lui	v0,0xb404
bfc02100:	afbf001c 	sw	ra,28(sp)
bfc02104:	afb20018 	sw	s2,24(sp)
bfc02108:	afb10014 	sw	s1,20(sp)
bfc0210c:	afb00010 	sw	s0,16(sp)
bfc02110:	00809021 	move	s2,a0
bfc02114:	0ff007a0 	jal	bfc01e80 <reset_gpio>
bfc02118:	24501000 	addiu	s0,v0,4096
bfc0211c:	0ff007f9 	jal	bfc01fe4 <nand_flash_init>
...

Best Regards,
PRC
Jul 15,2010

Re: Can objdump show friendly symbolic function name?

[Michael Hennebry]

On Thu, 15 Jul 2010, Pan ruochen wrote:

> I am developing with mips-linux toolchain. I always need to do some
> analysis on the disassembly code.
> But objdump displays as following:

> 0001c370 <semget>:
>   1c370:   3c1c0005    lui gp,0x5
>   1c374:   279ce080    addiu   gp,gp,-8064
>   1c378:   0399e021    addu    gp,gp,t9


>   1c3a4:   00802821    move    a1,a0
>   1c3a8:   afa00010    sw  zero,16(sp)
>   1c3ac:   afa00014    sw  zero,20(sp)
>   1c3b0:   0320f809    jalr    t9

> It is really hard to read disassembly code like that since I can't see which
> function is called from `jalr t9'.
>
> Is there some way to inform objdump to display more friendly symbolic name
> as following?

I think that -S will do roughly what you want.

-- 
Michael   hennebry@web.cs.ndsu.NoDak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."

Re: Can objdump show friendly symbolic function name?

[Pan ruochen]

> I think that -S will do roughly what you want.
>
> --
> Michael   hennebry@web.cs.ndsu.NoDak.edu
> "Pessimist: The glass is half empty.
> Optimist:   The glass is half full.
> Engineer:   The glass is twice as big as it needs to be."
>

'mips-linux-gnu-objdump -d -r _uclibc/lib/libuClibc-0.9.30.so'
and
'mips-linux-gnu-objdump -d -r -S _uclibc/lib/libuClibc-0.9.30.so'
make no difference.


Best Regards,
PRC
Jul 15,2010

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Thu, 15 Jul 2010, Pan ruochen wrote:

> I am developing with mips-linux toolchain. I always need to do some
> analysis on the disassembly code.
> But objdump displays as following:
> ----------------------------------------------------------------------------------------
> 0001c370 <semget>:
>    1c370:   3c1c0005    lui gp,0x5
>    1c374:   279ce080    addiu   gp,gp,-8064
>    1c378:   0399e021    addu    gp,gp,t9
>    1c37c:   27bdffd8    addiu   sp,sp,-40
>    1c380:   afbf0024    sw  ra,36(sp)
>    1c384:   afbc0018    sw  gp,24(sp)
>    1c388:   00a01021    move    v0,a1
>    1c38c:   00c03821    move    a3,a2
>    1c390:   00403021    move    a2,v0
>    1c394:   8f828880    lw  v0,-30592(gp)
>    1c398:   8f998204    lw  t9,-32252(gp)
>    1c39c:   2403ffff    li  v1,-1
>    1c3a0:   ac430000    sw  v1,0(v0)
>    1c3a4:   00802821    move    a1,a0
>    1c3a8:   afa00010    sw  zero,16(sp)
>    1c3ac:   afa00014    sw  zero,20(sp)
>    1c3b0:   0320f809    jalr    t9
>    1c3b4:   24040002    li  a0,2
>    1c3b8:   8fbf0024    lw  ra,36(sp)
>    1c3bc:   8fbc0018    lw  gp,24(sp)
>    1c3c0:   03e00008    jr  ra
>    1c3c4:   27bd0028    addiu   sp,sp,40
> ----------------------------------------------------------------------------------------
> 
> It is really hard to read disassembly code like that since I can't see which
> function is called from `jalr t9'.

 Fair enough.

 You *might* be able to get some more information about the symbol the PIC 
call instruction refers to if you use "-r" to intersperse relocations with 
the disassembly -- there may be a call hint relocation associated with 
"jalr $t9".  Then again, maybe not.  It's only an optimisation hint.

 Failing that you can only track down manually what "lw t9,-32252(gp)" 
refers to.  Try `readelf -A' as an aid.

 Teaching `objdump' what symbol this instruction's memory operand refers 
to would be a nice, but I fear that quite a non-trivial enhancement.  And 
you can't do that for actual call instructions that use the register mode 
as static analysis is certainly beyond the scope of `objdump'.

> Is there some way to inform objdump to display more friendly symbolic name
> as following?
> 
> bfc020f8 <try_nand_flash_boot>:
> bfc020f8:	27bdffe0 	addiu	sp,sp,-32
> bfc020fc:	3c02b404 	lui	v0,0xb404
> bfc02100:	afbf001c 	sw	ra,28(sp)
> bfc02104:	afb20018 	sw	s2,24(sp)
> bfc02108:	afb10014 	sw	s1,20(sp)
> bfc0210c:	afb00010 	sw	s0,16(sp)
> bfc02110:	00809021 	move	s2,a0
> bfc02114:	0ff007a0 	jal	bfc01e80 <reset_gpio>
> bfc02118:	24501000 	addiu	s0,v0,4096
> bfc0211c:	0ff007f9 	jal	bfc01fe4 <nand_flash_init>
> ...

 There's no such problem with non-PIC objects like this one because 
addresses used by call instructions are immediates (or the instructions 
have relocations associated) that can be cross-referred to the symbol 
table.

  Maciej

Re: Can objdump show friendly symbolic function name?

[Pan ruochen]

Hi Maciej

Thanks for the hints.
I have taken some time to write a tiny tool to patch the objdump
outputs since there is no way to display friendly symbolic function
names.
I hope the tool will be useful to somebody else in the future.

================================================
#
#  Show friendly symbolic names for PIC ELF.
#
#  BY P.R.C <panruochen@gmail.com>
#  Jul 15,2010
gawk '
FILENAME==ARGV[1] {
	symbols[$1] = $3;
}
FILENAME==ARGV[2]{
	if($1=="Local"  && $2=="entries:") {
		flag = 1
		next
	} else if($1=="Global" && $2=="entries:") {
		flag = 2
		next
	}
	if( $1 ) {
		if ( flag == 1 ) {
			if ( $3 in symbols )
				name = symbols[$3];
			else
				name = $3
			gp_local[$2] = name
		} else if( flag == 2 ) {
			gp_global[$2] = $7
		}
	}
}
FILENAME==ARGV[3] {
	n = match($0, /[ls]w	t9,(.+\(gp\))/, m);
	if(n > 0) {
		gp = substr($0, m[1,"start"], m[1,"length"]);
		if( gp in gp_local )
			name = gp_local[gp];
		else if ( gp in gp_global )
			name = gp_global[gp];
	}
	if( name != "" )
		printf("%s <%s>\n", $0, name)
	else
		print $0
	name = "";
} ' libuClibc.map libuClibc.gp libuClibc.lst
================================================

usage:
$mips-linux-gnu-objdump -d libuClibc.so >  libuClibc.lst
$mips-linux-gnu-readelf -A libuClibc.so >  libuClibc.gp
$mips-linux-gnu-nm -D libuClibc.so >  libuClibc.map
$./pic-elf-objdump.sh

The output is patched as following:
-------------------------------------------------------------------------
000144a4 <regfree>:
   144a4:	3c1c0005 	lui	gp,0x5
   144a8:	279c5f4c 	addiu	gp,gp,24396
   144ac:	0399e021 	addu	gp,gp,t9
   144b0:	27bdffe0 	addiu	sp,sp,-32
   144b4:	afbf001c 	sw	ra,28(sp)
   144b8:	afb00018 	sw	s0,24(sp)
   144bc:	afbc0010 	sw	gp,16(sp)
   144c0:	00808021 	move	s0,a0
   144c4:	8f998814 	lw	t9,-30700(gp) <free>
   144c8:	0320f809 	jalr	t9
   144cc:	8c840000 	lw	a0,0(a0)
   144d0:	8fbc0010 	lw	gp,16(sp)
   144d4:	8e040010 	lw	a0,16(s0)
   144d8:	ae000000 	sw	zero,0(s0)
   144dc:	8f998814 	lw	t9,-30700(gp) <free>
   144e0:	ae000004 	sw	zero,4(s0)
   144e4:	0320f809 	jalr	t9
   144e8:	ae000008 	sw	zero,8(s0)
   144ec:	8fbc0010 	lw	gp,16(sp)
   144f0:	8e02001c 	lw	v0,28(s0)
   144f4:	8e040014 	lw	a0,20(s0)
   144f8:	8f998814 	lw	t9,-30700(gp) <free>
-------------------------------------------------------------------------

>
>  There's no such problem with non-PIC objects like this one because
> addresses used by call instructions are immediates (or the instructions
> have relocations associated) that can be cross-referred to the symbol
> table.
>
>  Maciej
>

Re: Can objdump show friendly symbolic function name?

[Michael Hennebry]

On Thu, 15 Jul 2010, Pan ruochen wrote:

>> I think that -S will do roughly what you want.

> 'mips-linux-gnu-objdump -d -r _uclibc/lib/libuClibc-0.9.30.so'
> and
> 'mips-linux-gnu-objdump -d -r -S _uclibc/lib/libuClibc-0.9.30.so'
> make no difference.

I'm surprised.
avr-objdump -S is what I and other guys at www.avrfreaks.net use.
Of course, we aren't using it on shared libraries,
just "executable" .elf files.

-- 
Michael   hennebry@web.cs.ndsu.NoDak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."

Re: Can objdump show friendly symbolic function name?

[Richard Sandiford]

Pan ruochen <panruochen@gmail.com> writes:
> I have taken some time to write a tiny tool to patch the objdump
> outputs since there is no way to display friendly symbolic function
> names.
> I hope the tool will be useful to somebody else in the future.

Thanks for posting the script.  I'm sure people will find it useful.

It would certainly be possible to do the same thing in objdump,
and FWIW, I did wonder about that when adding the readelf -A GOT dump.
The problem is that, in a multi-GOT world, the annotations are only
ever going to be a best guess.  If the disassembler sees:

     lw    $2,-32000(gp)

it doesn't in general know whether gp points to the primary
(ABI-defined) GOT, or to some secondary GOT.  If it guesses
right, the annotation would be useful, but if it guesses wrong,
the annotation would be very misleading.  This is different from
the current <foo> markers, which are always accurate (or at least,
_should_ always be accurate).

A compromise would be to add an option that provides more
"guess"-level annotations.

As Maciej says, the most reliable way is to disassemble objects
that still have relocations in them.  Are you linking the objects
yourself?  If so, it's worth considering linking with -Wl,-q
(aka -Wl,--emit-relocs).  Then objdump -dr will tell you where
each jump went.

If you're not linking the objects yourself, I agree a script
like yours is the best way to go.  Users of scripts are more
likely to be aware that what the script is doing isn't quite
the same as the normal objdump behaviour (but is useful
nonetheless).

Richard

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Mon, 19 Jul 2010, Richard Sandiford wrote:

> It would certainly be possible to do the same thing in objdump,
> and FWIW, I did wonder about that when adding the readelf -A GOT dump.
> The problem is that, in a multi-GOT world, the annotations are only
> ever going to be a best guess.  If the disassembler sees:
> 
>      lw    $2,-32000(gp)
> 
> it doesn't in general know whether gp points to the primary
> (ABI-defined) GOT, or to some secondary GOT.  If it guesses
> right, the annotation would be useful, but if it guesses wrong,
> the annotation would be very misleading.  This is different from
> the current <foo> markers, which are always accurate (or at least,
> _should_ always be accurate).

 Can the GOT pointer switch between GOTs within a single function?

  Maciej

Re: Can objdump show friendly symbolic function name?

[John Reiser]

>  Can the GOT pointer switch between GOTs within a single function?

A function which references more than  ((1<<16) / sizeof(void *))
external symbols must use more than one GOT.

-- 

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Tue, 20 Jul 2010, John Reiser wrote:

> >  Can the GOT pointer switch between GOTs within a single function?
> 
> A function which references more than  ((1<<16) / sizeof(void *))
> external symbols must use more than one GOT.

 That's a corner case that I wouldn't be surprised if it wasn't handled at 
all -- that's a *huge* lot of global symbols to refer to from a single 
function (where good programming rules mandate limiting the use of global 
variables to the absolutely necessary minimum).  And switching GOTs in the 
middle of a function is complicated -- $t9 is not available anymore and 
the only way to retrieve the PC is one of the branch-and-link 
instructions.  Or alternatively the current GOT pointer can be used to 
offset against.  Either way rather painful.  Then you need to track 
backward branches to switch back as appropriate, etc., etc.

 A common case where a single 16-bit GOT doesn't suffice is the whole 
binary object, either an executable or a shared module, where it's only 
each function's prologue that you have to pick the right GOT pointer.  I 
can't recall seeing code in binutils to handle GOT switches within 
functions and hence my question.

  Maciej

Re: Can objdump show friendly symbolic function name?

[John Reiser]

>>>  Can the GOT pointer switch between GOTs within a single function?

>> A function which references more than  ((1<<16) / sizeof(void *))
>> external symbols must use more than one GOT.

>  That's a corner case that I wouldn't be surprised if it wasn't handled at 
> all -- ...    switching GOTs in the middle of a function is complicated -- ... 
> alternatively the current GOT pointer can be used to offset against.
> Either way rather painful.  Then you need to track
> backward branches to switch back as appropriate, etc., etc.

One way to handle the overflow is to put a vector of pointers to every GOT_i
at some fixed offset in each GOT:

   GOT0: .addr GOT0, GOT1, GOT2, GOT3
	...
   GOT1: .addr GOT0, GOT1, GOT2, GOT3
	...
   GOT2: .addr GOT0, GOT1, GOT2, GOT3
	...
   GOT3: .addr GOT0, GOT1, GOT2, GOT3
	...
Then you don't need to _switch_, you just suffer an indirection
(another load with delay slot) for outlanders.  For a FETCH to GPR
the indirection can use the same register as the destination,
else use $AT as for a STORE.  Yes, the compiler must be told
to generate such code.

-- 

Re: Can objdump show friendly symbolic function name?

[David Daney]

On 07/20/2010 08:19 AM, John Reiser wrote:
>>>>   Can the GOT pointer switch between GOTs within a single function?
>
>>> A function which references more than  ((1<<16) / sizeof(void *))
>>> external symbols must use more than one GOT.
>
>>   That's a corner case that I wouldn't be surprised if it wasn't handled at
>> all -- ...    switching GOTs in the middle of a function is complicated -- ...
>> alternatively the current GOT pointer can be used to offset against.
>> Either way rather painful.  Then you need to track
>> backward branches to switch back as appropriate, etc., etc.
>
> One way to handle the overflow is to put a vector of pointers to every GOT_i
> at some fixed offset in each GOT:
>
>     GOT0: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>     GOT1: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>     GOT2: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>     GOT3: .addr GOT0, GOT1, GOT2, GOT3
> 	...
> Then you don't need to _switch_, you just suffer an indirection
> (another load with delay slot) for outlanders.  For a FETCH to GPR
> the indirection can use the same register as the destination,
> else use $AT as for a STORE.  Yes, the compiler must be told
> to generate such code.
>

I would note that GCC/Binutils has for quite some time had the -mxgot 
option (or a variant thereof), which lifts the got size restriction at 
the expense of less efficient code.  I would be inclined to recommend 
using it instead of cooking up a solution for multiple GOTs within a 
single function.  It has the advantage that it exists and works today.

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.

David Daney

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Tue, 20 Jul 2010, John Reiser wrote:

> >  That's a corner case that I wouldn't be surprised if it wasn't handled at 
> > all -- ...    switching GOTs in the middle of a function is complicated -- ... 
> > alternatively the current GOT pointer can be used to offset against.
> > Either way rather painful.  Then you need to track
> > backward branches to switch back as appropriate, etc., etc.
> 
> One way to handle the overflow is to put a vector of pointers to every GOT_i
> at some fixed offset in each GOT:
> 
>    GOT0: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>    GOT1: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>    GOT2: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>    GOT3: .addr GOT0, GOT1, GOT2, GOT3
> 	...
> Then you don't need to _switch_, you just suffer an indirection
> (another load with delay slot) for outlanders.  For a FETCH to GPR
> the indirection can use the same register as the destination,
> else use $AT as for a STORE.

 Of course, that sounds obvious to me even, but then you wouldn't have the 
problem with decoding <offset>($gp) references concerned here as $gp would 
always point to the same GOT throughout a function.  Note the serious 
performance penalty to access "outlanders", especially on load-delay slot 
platforms.

>  Yes, the compiler must be told
> to generate such code.

 Not quite so -- GAS already does this sort of macro expansion already, at 
least for the MIPS target, as it has to choose between local and global 
symbol references, if nothing else, that may not always be told apart 
until all the file has been assembled -- see how LW and friends are 
implemented.

  Maciej

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Tue, 20 Jul 2010, David Daney wrote:

> I would note that GCC/Binutils has for quite some time had the -mxgot option
> (or a variant thereof), which lifts the got size restriction at the expense of
> less efficient code.  I would be inclined to recommend using it instead of
> cooking up a solution for multiple GOTs within a single function.  It has the
> advantage that it exists and works today.

 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.

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

  Maciej

Re: Can objdump show friendly symbolic function name?

[David Daney]

On 07/20/2010 09:59 AM, Maciej W. Rozycki wrote:
> On Tue, 20 Jul 2010, David Daney wrote:
>
>> I would note that GCC/Binutils has for quite some time had the -mxgot option
>> (or a variant thereof), which lifts the got size restriction at the expense of
>> less efficient code.  I would be inclined to recommend using it instead of
>> cooking up a solution for multiple GOTs within a single function.  It has the
>> advantage that it exists and works today.
>
>   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.

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

David Daney

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

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

Re: Can objdump show friendly symbolic function name?

[Daniel Jacobowitz]

On Tue, Jul 20, 2010 at 06:32:36PM +0100, Maciej W. Rozycki wrote:
> > 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.

Everything linked in to the executable has to use -mxgot - or you have
to be lucky.  The usual problem was that one of crtbegin or crtend
would have a GOT reference that ended up out of range.  That's all I
remember, though.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Tue, 20 Jul 2010, Daniel Jacobowitz wrote:

> >  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.
> 
> Everything linked in to the executable has to use -mxgot - or you have
> to be lucky.  The usual problem was that one of crtbegin or crtend
> would have a GOT reference that ended up out of range.  That's all I
> remember, though.

 Well, rebuilding crt* files with -mxgot (with GLIBC there's that 
libc_nonshared.a thing too) still looks to me like much less effort than 
implementing multi-GOT support in binutils. ;)

  Maciej

Re: Can objdump show friendly symbolic function name?

[Pan ruochen]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

>2010/7/20 Maciej W. Rozycki <macro@linux-mips.org>:
> On Mon, 19 Jul 2010, Richard Sandiford wrote:
>
>> It would certainly be possible to do the same thing in objdump,
>> and FWIW, I did wonder about that when adding the readelf -A GOT dump.
>> The problem is that, in a multi-GOT world, the annotations are only
>> ever going to be a best guess.  If the disassembler sees:
>>
>>      lw    $2,-32000(gp)
>>
>> it doesn't in general know whether gp points to the primary
>> (ABI-defined) GOT, or to some secondary GOT.  If it guesses
>> right, the annotation would be useful, but if it guesses wrong,
>> the annotation would be very misleading.  This is different from
>> the current <foo> markers, which are always accurate (or at least,
>> _should_ always be accurate).
>
>  Can the GOT pointer switch between GOTs within a single function?
>
>  Maciej
>

I don't have a multi-got ELF at hand. I have no idea what the objudmp
format look like for a multi-got ELF.
The guess ability of the script will be improved in the future when me
or somebody else get a multi-got ELF.

By now, I just modify the script a little to make it easier for the user.
The use can simply run `pic-elf-objdump.sh UR_ELF' to get the guess
function calls.


PRC
Jul 21,2010

[-- Attachment #2: pic-elf-objdump.sh --]
[-- Type: application/x-sh, Size: 1099 bytes --]

Re: Can objdump show friendly symbolic function name?

[Richard Sandiford]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Mon, 19 Jul 2010, Richard Sandiford wrote:
>> It would certainly be possible to do the same thing in objdump,
>> and FWIW, I did wonder about that when adding the readelf -A GOT dump.
>> The problem is that, in a multi-GOT world, the annotations are only
>> ever going to be a best guess.  If the disassembler sees:
>> 
>>      lw    $2,-32000(gp)
>> 
>> it doesn't in general know whether gp points to the primary
>> (ABI-defined) GOT, or to some secondary GOT.  If it guesses
>> right, the annotation would be useful, but if it guesses wrong,
>> the annotation would be very misleading.  This is different from
>> the current <foo> markers, which are always accurate (or at least,
>> _should_ always be accurate).
>
>  Can the GOT pointer switch between GOTs within a single function?

No.

Richard

Re: Can objdump show friendly symbolic function name?

[Richard Sandiford]

Daniel Jacobowitz <dan@codesourcery.com> writes:
> On Tue, Jul 20, 2010 at 06:32:36PM +0100, Maciej W. Rozycki wrote:
>> > 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.
>
> Everything linked in to the executable has to use -mxgot - or you have
> to be lucky.  The usual problem was that one of crtbegin or crtend
> would have a GOT reference that ended up out of range.  That's all I
> remember, though.

Right.  The problem is that the way the linker orders the GOT isn't
easily predictable.  What you want in the ideal world is for all GOT
entries that only referenced by {GOT,CALL}_{HI,LO}16 relocs to come
after all those that are referenced using single 16-bit relocs like GOT16.
But at the moment, that's not always the case, and an arbitrary symbol
referenced by a 16-bit reloc could be placed after several symbols that
aren't.

This should now be relatively straightforward to fix, but I never got
around to it.  See:

   http://sourceware.org/ml/binutils/2008-06/msg00274.html

for a sketch of one possible approach (and still my preferred one).

Richard

Re: Can objdump show friendly symbolic function name?

[Richard Sandiford]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> 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.

I don't recall multi-GOT being motivated by a single program, although
I could be wrong.  It was something that SGI tools did well before ours,
and ISTR one of Red Hat's customers specifically wanted the same feature
on GNU/Linux.

Alex seems to suggest that gdb failed to build on IRIX without it:

    http://sourceware.org/ml/binutils/2003-01/msg00165.html

IMO, multi-GOT's a nice, efficient way of building big shared libraries
(which seem to be all the rage these days ;-)).  It makes the overhead
of -mxgot redundant unless (a) you've got a humungous function or
(b) you "need" to create big intermediate objects with -r.  Plus it's
easier to use: no need to recompile objects until everything magically
fits.

Richard

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Wed, 21 Jul 2010, Richard Sandiford wrote:

> >> It would certainly be possible to do the same thing in objdump,
> >> and FWIW, I did wonder about that when adding the readelf -A GOT dump.
> >> The problem is that, in a multi-GOT world, the annotations are only
> >> ever going to be a best guess.  If the disassembler sees:
> >> 
> >>      lw    $2,-32000(gp)
> >> 
> >> it doesn't in general know whether gp points to the primary
> >> (ABI-defined) GOT, or to some secondary GOT.  If it guesses
> >> right, the annotation would be useful, but if it guesses wrong,
> >> the annotation would be very misleading.  This is different from
> >> the current <foo> markers, which are always accurate (or at least,
> >> _should_ always be accurate).
> >
> >  Can the GOT pointer switch between GOTs within a single function?
> 
> No.

 I suppose it should be moderately easy to decode the prologue of each 
function then to see which GOT $gp refers to.

  Maciej

Re: Can objdump show friendly symbolic function name?

[David Daney]

On 07/22/2010 04:57 AM, Maciej W. Rozycki wrote:
> On Wed, 21 Jul 2010, Richard Sandiford wrote:
>
>>>> It would certainly be possible to do the same thing in objdump,
>>>> and FWIW, I did wonder about that when adding the readelf -A GOT dump.
>>>> The problem is that, in a multi-GOT world, the annotations are only
>>>> ever going to be a best guess.  If the disassembler sees:
>>>>
>>>>       lw    $2,-32000(gp)
>>>>
>>>> it doesn't in general know whether gp points to the primary
>>>> (ABI-defined) GOT, or to some secondary GOT.  If it guesses
>>>> right, the annotation would be useful, but if it guesses wrong,
>>>> the annotation would be very misleading.  This is different from
>>>> the current<foo>  markers, which are always accurate (or at least,
>>>> _should_ always be accurate).
>>>
>>>   Can the GOT pointer switch between GOTs within a single function?
>>
>> No.
>
>   I suppose it should be moderately easy to decode the prologue of each
> function then to see which GOT $gp refers to.
>

Modern GCCs will not generate a fixed function prologue layout, and for 
leaf functions the GP will not necessarily be in $28.  Add in the 
difference caused by -mshared and -mplt, and there can be quite a bit of 
variability.

I think it is still technically feasible, but it could be a rather large 
piece of code.  I would note that this problem is similar to the problem 
of generating a stack trace by using code inspection.  It is possible, 
but using real debugging info is far better.

David Daney

Re: Can objdump show friendly symbolic function name?

[Maciej W. Rozycki]

On Thu, 22 Jul 2010, David Daney wrote:

> >   I suppose it should be moderately easy to decode the prologue of each
> > function then to see which GOT $gp refers to.
> 
> Modern GCCs will not generate a fixed function prologue layout, and for leaf
> functions the GP will not necessarily be in $28.  Add in the difference caused
> by -mshared and -mplt, and there can be quite a bit of variability.

 GDB largely relies on the ability to decode function prologues and from 
my experience it has worked pretty well.  I see no reason why other tools 
couldn't follow if need be.

> I think it is still technically feasible, but it could be a rather large piece
> of code.  I would note that this problem is similar to the problem of
> generating a stack trace by using code inspection.  It is possible, but using
> real debugging info is far better.

 You only need to get your hands on $gp here and the ABI pretty much 
constrains the sequences used to be that emitted by .cpload/.cpsetup as 
applicable.  There's little room for variance here as software relies on 
them for various purposes you may have no idea of (which is the point of 
any standardisation).

 Even then, if the prologue scanner fails to see any of the sequences 
permitted, then you'll just get no symbol references as you do today.  I 
do not ask for handling .cplocal -- that's probably too tricky, at least 
for a start, and too much of a corner case (mostly useful for leaf 
functions -- I haven't checked how much, if at all, GCC makes use of it).

  Maciej