This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] (version 2) Change MIPS linker stubs to allow for more than 2^15 symbols.
Thiemo Seufer wrote:
Richard Sandiford wrote:
David Daney <email@example.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