GNU linker and Function stubs on mips.

Koundinya K
Sat Feb 26 10:25:00 GMT 2000


I have been compiling a couple of things with the newly built gcc.
Sometimes some programs fail citing "procedure referencing errors from
the dynanic linker". But the programs work when the LD_BIND_NOW
environment flag is turned on ( The LD_BIND_NOW environment variable can
change the behavior of dynamic linking. When turned on, the dynamic
linker evalutes all symbol table entries of the type STT_FUNC, replacing
their stub address in the GOT with the actual addresses of the
referenced function ).

One thing I see with the GNU linker is that all the undefined symbols of
the type STT_FUN  contain stub address.

In the case of natively linked program not all symbols the same type
contain stub addresses.

Here is a hello linked from the native compiler / linker. Below are
shown some entries of the symbol table.

 29: 00000000    56 FUNC    GLOBAL DEFAULT  0  UND _cleanup
 42: 00400780    92 FUNC    GLOBAL DEFAULT  0  UND exit
 47: 00000000   372 FUNC    GLOBAL DEFAULT  0  UND printf

See the similar entries of the symbol table in case of hello from
GNU ld.

19: 00400820    56 FUNC    GLOBAL DEFAULT  0  UND _cleanup
20: 00400810   372 FUNC    GLOBAL DEFAULT  0  UND printf

As you can see the in the case of a GNU linked binary there are always
stub addresses.

This is something similar to what hppens in IRIX6*. The native IRIX6*
Linker just works this way.

But I think for normal/traditional mips targets it is not the case.

Here is something that I repeat from the MIPS ABI:

Undefined symbols of the type STT_FUN, which have been referenced by
R_MIPS_CALL16 and R_MIPS_26 relocations can contain on zero values in
their st_value field, denoting the stub addresses used for lazy
evaluation for this symbol. The run time linker uses this to reset the
GOT entry for this external to its stub address when unlinking a shared
object. All othe undefined symbols must contain zero in their st_value

I have takes several object files having all possible relocs and tried
to link with the GNU linker. It sets the stubs for all symbols ,
irrespective of the relocs. So it looks like the default behavior of the
GNU linker is to set up stubs for lazy binding.

I tried to figure out to see how the GNU linker checks if a particular
symbol requires a stub or not. But looks like no where such checks are
done. For all the symbols stubs are generated.  In particular I was
looking through where the st_value for a symbol is assigned at first and
is there any sort of test done before this is assigned. But got no clues

Any pointers or information on this will be helpful

Thanks a lot !!

With best regards


More information about the Binutils mailing list