GNU linker and Function stubs on mips.

[Koundinya K]

Hi,

Ian Lance Taylor wrote:

>    Date: Fri, 03 Mar 2000 07:34:42 -0700
>    From: Koundinya K <knk@dde.dk>
>
>    Yes you are right. In fact even in the second test we don't need to test for
>    STT_FUNC at all.
>
> Will that really handle weakdefs correctly?  Make sure you think about
> the consequences of your changes with respect to the existing code.
> Just because it works for your test case does not mean that it works
> for all test cases.
>

Yes, surely I will try all possible test cases.

> Build a shared library out of that code.  Look at the dynamic symbol
> entry for foo.  Try this with the native tools and the patched GNU
> linker.

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



>
> You are suggesting that we only need to check NEEDS_PLT.  Therefore, I
> am constructing a test case which I believe will set NEEDS_PLT, but
> which also refers to the symbol without calling it.  It's clear that
> you have tested symbols which are called, since that is done by any
> actual program.  It's clear that you have tested symbols whose address
> is taken, since that is the bug you are fixing.  It is not clear that
> you have tested symbols which are both called and whose address is
> taken.
>
> I am suggesting that you look at the dynamic symbol entry for such a
> symbol, because that is what your patch affects.  This should actually
> be done with the symbol both defined and undefind.

Once this patch gets a bit stable, I will plan for solid testing.

Thanks !!


koundinya

>
> Ian