Re: GNU linker and Function stubs on mips.

[Koundinya K <knk at dde dot dk>]

Hi Ian,

I have been doing some testing with  simple test cases and comparing the resullts of
the GNU linker against the native tools.

It looks like a bit of care should be taken while initializing the entries in the
GOT. Especailly when generating shared lbs.

But before that, Y'day I wrote:

Koundinya K wrote:

>
>
> I generated the shared libs from from the test case you provided using native
> tools and the GNU linker. I got the same results. In both the cases the dynamic
> symbol table entry for foo is 0.
>
> BUT.... the native generated shared lib has the corresponding GOT entry for foo
> also as zero.
>
> But the GNU linker generated shared lib does not have zero in the GOT entry. It
> contains some address. This is theoretically and practically wrong I think.
>
> This is because in the object file foo is of the type NOTYPE. Both the .o (object)
> files one generated from native compiler and the other from gcc have put in foo as
> NOTYPE in the object files. The .o files are exactly identical. foo does not come
> over to adjust_dynamic_symbol(). Probably something has to be done in
> finish_dynamic_symbol() to trap these type of symbols and then initialize the
> GOT entry to zero.
>
> What do you say ??

O.K, I have made this change in finish_dynamic_symbol:

*************** _bfd_mips_elf_finish_dynamic_symbol (out
*** 8185,8196 ****
--- 8297,8314 ----
        if (sym->st_value)
        value = sym->st_value;
        else
+         {
            /* For an entity defined in a shared object, this will be
               NULL.  (For functions in shared objects for
               which we have created stubs, ST_VALUE will be non-NULL.
               That's because such the functions are now no longer defined
               in a shared object.)  */
+
+           if (info->shared && (h->root.type == bfd_link_hash_undefined))
+             value = 0;
+           else
              value = h->root.u.def.value;
+         }


BTW, I am a little confused about the comment.


To begin with  here is one very simple test case that I took to see about the weak
symbol handling.

halfway:3554 [knk/work/hello] cat weak.c
#pragma weak _fun = fun

void fun()
{
}

halfway:3557 [knk/work/hello] cat weakcall.c
extern void fun();

void call_fun()
{
fun();
}

I generated a shared library out of these two object files. One from native tools and
the other from the GNU linker.

Both the libs are identical with respect to thier dynamic symbol table entries. No
problem there.

But for fun() in the natively generated lib the GOT entry contains 0.

                Index   Content  gp_reladdr   Address
.got
.....................................
....................................
....................................
Global Symbols :
0x00000000 -32724(gp), 0x0001051c [fun]


The shared lib generated from the GNU linker shows this in the GOT

             Index   Content  gp_reladdr   Address
.got
.....................................
....................................
....................................
Global Symbols :
0x5ffe0508 -32724(gp), 0x6002062c [fun]

The reloc type for fun is R_MIPS_GO16 is weakcall.o. fun() does not require a PLT
entry. But since this symbol does not come over to adjust_dynamic_symbol(), rather
these should be handled in finish_dynamic_symbol() to check that the GOT entry for
them is initialized to 0.

I think if info->shared is true and either  of these flag are set for the symbol

o Symbol has a non-weak reference from a non-shared object
o Symbol is defined by a non-shared object
o Symbol is referenced by a non-shared object

then the GOT entry for this symbol should be zero.

This can be handled in finish_dynamic_symbol()


I am really going mad !! :-(((

Please provide your views or do you have any other suggestion ??

Thanks a lot.

With best regards

Koundinya