public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Ian Lance Taylor <iant@google.com>
Cc: binutils@sourceware.org
Subject: Re: PATCH: PR gold/13507: Gold assumes GOT entry size is the same as ELF class size
Date: Fri, 16 Dec 2011 15:39:00 -0000	[thread overview]
Message-ID: <CAMe9rOrXivTFYsadrAH_E6SHcPv_gppz0uNCRcxBWPcZ2EMJjA@mail.gmail.com> (raw)
In-Reply-To: <mcr8vmdjc59.fsf@dhcp-172-18-216-180.mtv.corp.google.com>

On Thu, Dec 15, 2011 at 9:53 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Thu, Dec 15, 2011 at 6:37 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>>>
>>>> This patch adds a parameter, got_entry_size, to Output_data_got
>>>> constructor so that a target can have a different GOT entry size.
>>>
>>> Why not just use Output_data_got<got_entry_size, endianness>?
>>>
>>> Ian
>>
>> There are
>>
>> template<int size, bool big_endian>
>> class Output_data_got : public Output_section_data_build
>> {
>>  public:
>>   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;
>> ....
>>   bool
>>   add_local(Sized_relobj_file<size, big_endian>* object, unsigned int sym_index,
>>             unsigned int got_type);
>>
>>   // Like add_local, but use the PLT offset of the local symbol if it
>>   // has one.
>>   bool
>>   add_local_plt(Sized_relobj_file<size, big_endian>* object,
>>                 unsigned int sym_index,
>>                 unsigned int got_type);
>>
>>   // Add an entry for a local symbol to the GOT, and add a dynamic
>>   // relocation of type R_TYPE for the GOT entry.
>>   void
>>   add_local_with_rel(Sized_relobj_file<size, big_endian>* object,
>>                      unsigned int sym_index, unsigned int got_type,
>>                      Rel_dyn* rel_dyn, unsigned int r_type);
>>
>>   void
>>   add_local_with_rela(Sized_relobj_file<size, big_endian>* object,
>>                       unsigned int sym_index, unsigned int got_type,
>>                       Rela_dyn* rela_dyn, unsigned int r_type);
>>
>> The "size" parameter is the ELF class size.  32bit ELF targets
>> have to use 32.
>
> Ah, I see.  Output_data_got does conflate the GOT entry size with the
> Sized_relobj_file<size, big_endian> argument.  Sorry to be a pain, but
> that is really an error in how Output_data_got is written.  The size
> should be the size of a GOT entry, not the ELF class size.  The
> arguments should be Relobj, not Sized_relobj_file.  Of course this will
> require some other work as well.

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.

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


-- 
H.J.

  reply	other threads:[~2011-12-16 15:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 23:09 H.J. Lu
2011-12-16  2:38 ` Ian Lance Taylor
2011-12-16  2:58   ` H.J. Lu
2011-12-16  5:53     ` Ian Lance Taylor
2011-12-16 15:39       ` H.J. Lu [this message]
2011-12-16 16:43         ` Ian Lance Taylor
2011-12-16 17:08           ` H.J. Lu
2011-12-16 19:00             ` Ian Lance Taylor
2011-12-16 22:10               ` H.J. Lu
2011-12-17  6:33                 ` Ian Lance Taylor
2011-12-17 17:11                   ` H.J. Lu
     [not found]                     ` <CAKOQZ8zjAStMvF0Di2V0tmbXSaJYgOx9uE3tYCW_CDS2n5-AkA@mail.gmail.com>
2012-01-02 17:09                       ` H.J. Lu
2012-01-02 18:27                         ` Ian Lance Taylor
2012-01-03 23:24                           ` Cary Coutant
2012-01-04  0:01                             ` Ian Lance Taylor
2012-01-04  0:25                               ` Cary Coutant
2011-12-16  3:19 ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMe9rOrXivTFYsadrAH_E6SHcPv_gppz0uNCRcxBWPcZ2EMJjA@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=iant@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).