understanding elf_machine_load_address

understanding elf_machine_load_address

[Guido Guenther]

Hi,
I'm trying to understand to following snippet from glibc's
sysdeps/mips/dl-machine.h:

elf_machine_load_address (void)
{
  ElfW(Addr) addr;
  asm ("	.set noreorder\n"
       "	la %0, here\n"
       "	bltzal $0, here\n"
       "	nop\n"
       "here:	subu %0, $31, %0\n"
       "	.set reorder\n"
       :	"=r" (addr)
       :	/* No inputs */
       :	"$31");
  return addr;
}

As of my understanding addr is zero since $31-%0 is always
zero(%0 stored (before the subu) the address of 'here', as does $31
after the bltzal). Please beat me with a cluebat.
 -- Guido

Re: understanding elf_machine_load_address

[Andreas Jaeger]

Guido Guenther <guido.guenther@gmx.net> writes:

> Hi,
> I'm trying to understand to following snippet from glibc's
> sysdeps/mips/dl-machine.h:

That one is really a bit tricky but it should be correct.

You should add the comment in front:
/* Return the run-time load address of the shared object.  */

> elf_machine_load_address (void)
> {
>   ElfW(Addr) addr;
>   asm ("	.set noreorder\n"
>        "	la %0, here\n"

load address this object has at build time (that's the address objdump
prints) and which is different than the current address (a shared
library can be loaded to any address and elf_machine_load_address is
called before relocation).

>        "	bltzal $0, here\n"
>        "	nop\n"
>        "here:	subu %0, $31, %0\n"

Subtract shared address of "here" from address of "here" at build time
- and you know at which address byte 0 of the shared library is
  loaded.

>        "	.set reorder\n"
>        :	"=r" (addr)
>        :	/* No inputs */
>        :	"$31");
>   return addr;
> }
>
> As of my understanding addr is zero since $31-%0 is always
> zero(%0 stored (before the subu) the address of 'here', as does $31
> after the bltzal). Please beat me with a cluebat.

Enough cluebat?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: understanding elf_machine_load_address

[Guido Guenther]

On Sat, Dec 08, 2001 at 04:18:53PM +0100, Andreas Jaeger wrote:
> Enough cluebat?
Yes. Thanks.
 -- Guido

Re: understanding elf_machine_load_address

[Daniel Jacobowitz]

On Sat, Dec 08, 2001 at 04:18:53PM +0100, Andreas Jaeger wrote:
> >        "	bltzal $0, here\n"
> >        "	nop\n"
> >        "here:	subu %0, $31, %0\n"
> 
> Subtract shared address of "here" from address of "here" at build time
> - and you know at which address byte 0 of the shared library is
>   loaded.

Wait a second.  Does bltzal fill in $31 even on a not-taken branch? 
Because bltzal $0 should never be taken.  My handy MIPS reference and
SPIM seem to agree that it won't fill in $31.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: understanding elf_machine_load_address

[Andreas Jaeger]

Daniel Jacobowitz <dan@debian.org> writes:

> On Sat, Dec 08, 2001 at 04:18:53PM +0100, Andreas Jaeger wrote:
>> >        "	bltzal $0, here\n"
>> >        "	nop\n"
>> >        "here:	subu %0, $31, %0\n"
>> 
>> Subtract shared address of "here" from address of "here" at build time
>> - and you know at which address byte 0 of the shared library is
>>   loaded.
>
> Wait a second.  Does bltzal fill in $31 even on a not-taken branch? 
> Because bltzal $0 should never be taken.  My handy MIPS reference and
> SPIM seem to agree that it won't fill in $31.

That's what I've asked myself also when fixing the dynamic linker.
But Ralf convinced me that $31 will get filled in (and I verified that
it did) - otherwise the dynamic linker would not work on any system at
all.

But it might be worth checking if Guido notices a problem.

Btw. could anybody send me a patch documenting this instruction so
that next time everybody knows directly what's going on?

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: understanding elf_machine_load_address

[Guido Guenther]

On Sat, Dec 08, 2001 at 08:42:32PM +0100, Andreas Jaeger wrote:
[..snip..] 
> That's what I've asked myself also when fixing the dynamic linker.
> But Ralf convinced me that $31 will get filled in (and I verified that
> it did) - otherwise the dynamic linker would not work on any system at
> all.
> 
> But it might be worth checking if Guido notices a problem.
Not in elf_machine_load_address but in _dl_runtime_resolve(see my other
posting), I just came across it when looking at dl-machine.h.
 -- Guido

Re: understanding elf_machine_load_address

[Andreas Jaeger]

Daniel Jacobowitz <dan@debian.org> writes:

> On Sat, Dec 08, 2001 at 04:18:53PM +0100, Andreas Jaeger wrote:
>> >        "	bltzal $0, here\n"
>> >        "	nop\n"
>> >        "here:	subu %0, $31, %0\n"
>> 
>> Subtract shared address of "here" from address of "here" at build time
>> - and you know at which address byte 0 of the shared library is
>>   loaded.
>
> Wait a second.  Does bltzal fill in $31 even on a not-taken branch? 
> Because bltzal $0 should never be taken.  My handy MIPS reference and
> SPIM seem to agree that it won't fill in $31.

I just checked the MIPS R4000 Microprocessor Manual, 2nd Ed. by Joe
Heinrich and it mentions "Unconditanally, the address of the
instruction after the delay slot is placed in the link register, $31".
Therefore the code is correct.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: understanding elf_machine_load_address

[Daniel Jacobowitz]

On Sat, Dec 08, 2001 at 09:52:01PM +0100, Andreas Jaeger wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> 
> > On Sat, Dec 08, 2001 at 04:18:53PM +0100, Andreas Jaeger wrote:
> >> >        "	bltzal $0, here\n"
> >> >        "	nop\n"
> >> >        "here:	subu %0, $31, %0\n"
> >> 
> >> Subtract shared address of "here" from address of "here" at build time
> >> - and you know at which address byte 0 of the shared library is
> >>   loaded.
> >
> > Wait a second.  Does bltzal fill in $31 even on a not-taken branch? 
> > Because bltzal $0 should never be taken.  My handy MIPS reference and
> > SPIM seem to agree that it won't fill in $31.
> 
> I just checked the MIPS R4000 Microprocessor Manual, 2nd Ed. by Joe
> Heinrich and it mentions "Unconditanally, the address of the
> instruction after the delay slot is placed in the link register, $31".
> Therefore the code is correct.

OK, thanks.  Yet another thing that changed between my simulator and my
hardware :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer