[PATCH] (version 2) Change MIPS linker stubs to allow for more than 2^15 symbols.

[David Daney]

Thiemo Seufer wrote:
> Richard Sandiford wrote:
> 
>>David Daney <ddaney@avtrex.com> writes:
>>
>>>! #define MIPS_FUNCTION_STUB_SIZE(INFO) \
>>>!   (elf_hash_table (INFO)->dynsymcount > 65536 ? 20 : 16)
>>
>>Sorry to be a pain, but as I said earlier, I really do think we should
>>cache the chosen stub size in mips_elf_link_hash_table (and get rid of
>>this macro entirely).  That will emphasise that always_size_dynamic_sections
>>is the place that makes the decision, and that it's only safe to use this
>>value once that function has been called.  I think that will be more robust
>>and easier to understand in future.
>>
>>Apart from that, and from Thiemo's and Daniel's comments, this looks
>>really good to me.  Thanks a lot for doing this!
> 
> 
> Does this followup patch look ok?
>

FWIW, it looks good to me.  Definitly a little cleaner than mine.

One weird thing is that the generated code is different.

My libgcj.so now has 16 byte stubs.  With my version of the patch it 
generated 20 byte stubs.  This means that at the point you are sampling 
info->dynsymcount, it had a different value than when it was sampled in 
my patch.  I was wondering about this because even though my patch 
generated 20 byte stubs, none of the symbol index values in the stubs 
were large enough to require the larger stub.

There must be more symbols that are added to the symbol table after 
_bfd_mips_elf_create_dynamic_sections is called.  Is it safe to assume 
that none of these 'extra' symbols will be referenced by a stub?

With your patch my simple tests with libgcj run successfully.  I did 
however see FAIL: MIPS multi-got-no-shared, which I think passed before 
applying your patch.  These are very brittle tests, so perhaps it is not 
surprising.


David Daney