This is the mail archive of the
mailing list for the binutils project.
Re: PATCH: PR gold/13507: Gold assumes GOT entry size is the same as ELF class size
"H.J. Lu" <email@example.com> writes:
> How do we deal with
> typedef typename elfcpp::Elf_types<size>::Elf_Addr Valtype;
> typedef Output_data_reloc<elfcpp::SHT_REL, true, size, big_endian> Rel_dyn;
> typedef Output_data_reloc<elfcpp::SHT_RELA, true, size, big_endian> Rela_dyn;
> <size> here should be the ELF class size.
As far as I can see in the definition of Valtype the size should be the
size of a GOT entry, not the ELF class size.
The simple way to handle Rel_dyn and Rela_dyn would be to change
Output_data_reloc<>::add_global and add_local to virtual functions, add
them to Output_data_reloc_generic, and use Output_data_reloc_generic in
Output_data_got. Perhaps that would lead to other issues, I'm not sure.
If that works it would let us eliminate add_global_with_rela and
Of course since add_global and add_local take addresses it would be
necessary for the generic versions to take uint64_t and for specific
versions to take the appropriate size address, and use convert_types to
make sure that there is no overflow. Actually it might be simpler to
leave add_global and add_local as they are and add virtual functions
with a different name to Output_data_reloc_generic.
>> In general I think the size of entries in the GOT ought to be a template
>> parameter for Output_data_got.
>> As far as I can tell your patch is incorrect, because you haven't
>> changed Output_data_got<size, big_endian>::Got_entry::write. ÂWhen that
>> function calls elfcpp::Swap<size, big_endian>::writeval, it has to use
>> the size of a GOT entry.
> How should it be fixed? Should we add another template parameter just
> for GOT entry size?
That would be another approach, yes.