Re: PATCH: PR gold/13507: Gold assumes GOT entry size is the same as ELF class size

[Ian Lance Taylor <iant at google dot com>]

"H.J. Lu" <hjl.tools@gmail.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
friends.

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.

Ian