public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Roland McGrath <mcgrathr@google.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] BFD vector for elf32-i386-nacl
Date: Tue, 26 Jul 2011 23:05:00 -0000	[thread overview]
Message-ID: <CAMe9rOpv+0noPiDa6fa+2oCx+j23xew1ntkHiDzUyoy04ZOXgQ@mail.gmail.com> (raw)
In-Reply-To: <CAB=4xhofYKpnCkkrL0nV9Gi0-D593PvY316kH5QqPK8JoJY=zQ@mail.gmail.com>

On Tue, Jul 26, 2011 at 2:20 PM, Roland McGrath <mcgrathr@google.com> wrote:
> elf_i386_link_hash_table is slightly overloaded for such uses (the
> is_vxworks and plt0_pad_byte fields), but IMHO that is a bad kludge.  The
> main purpose of that structure is for actual per-object data specific to
> the backend.  What I've added is constant per-backend data that will never
> vary across objects and it would be wasteful to duplicate it in the struct
> elf_i386_link_hash_table for each individual object.
>

Then can you move some fields from elf_i386_link_hash_table to
elf_i386_backend_data?

Thanks.

>
>
> On 7/26/11, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Jul 26, 2011 at 1:56 PM, Roland McGrath <mcgrathr@google.com> wrote:
>>> This patch adds the BFD target vector for the new target elf32-i386-nacl.
>>> This is to support Native Client (http://code.google.com/p/nativeclient/),
>>> which is a new pseudo-operating system that uses vanilla ELF but has a
>>> significantly nonstandard ABI.  (It is already known to config.sub as
>>> 'nacl'.)
>>>
>>> This is far from being complete support for this target, but it should
>>> be everything that will be needed in BFD proper.  It's gotten only the
>>> lightest testing, and of course the target-specific details are subject
>>> to potential fixes or changes later.
>>>
>>> I'm floating this early primarily to get feedback about the
>>> parameterization I've added to the shared elf32-i386.c code.
>>> The approach I took seems pretty clean to me, and moreso than
>>> e.g. the way vxworks was handled.
>>>
>>> I have tested that the i686-linux target still passes check-binutils and
>>> check-ld.  I'm not sure that tests much about correct PLT generation,
>>> which is the only area of the shared code really touched here.  If there
>>> are other good ways to test that (short of rebuilding a whole OS with
>>> this linker), please let me know.
>>>
>>> Ok for trunk?
>>>
>>> Thanks,
>>> Roland
>>>
>>>
>>> bfd/
>>> 2011-07-25  Roland McGrath  <mcgrathr@google.com>
>>>
>>>        * elf32-i386.c (NACL_PLT_ENTRY_SIZE, NACLMASK): New macros.
>>>        (elf_i386_nacl_plt0_entry): New variable.
>>>        (elf_i386_plt_entry): New variable.
>>>        (elf_i386_nacl_pic_plt0_entry): New variable.
>>>        (elf_i386_nacl_pic_plt_entry): New variable.
>>>        (elf_i386_nacl_arch_bed): New variable.
>>>        (elf_backend_arch_data): New macro setting for elf_i386_nacl_vec
>>> stanza.
>>>        (elf_backend_plt_alignment): Likewise.
>>>
>>>        * elf32-i386.c (struct elf_i386_backend_data): New type.
>>
>> We have elf_i386_link_hash_table for similar purpose.  Is that
>> possible to put elf_i386_backend_data fields there?
>>
>>
>> H.J.
>>
>



-- 
H.J.

  reply	other threads:[~2011-07-26 21:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-26 21:20 Roland McGrath
2011-07-26 21:23 ` H.J. Lu
2011-07-26 21:36   ` Roland McGrath
2011-07-26 23:05     ` H.J. Lu [this message]
     [not found]       ` <CAB=4xhp0Ctn3Kwq9JOQ5nWoN8NH_ejVLE0qJ61z2vK2L6fwjOA@mail.gmail.com>
2011-07-26 23:09         ` H.J. Lu
2011-07-26 23:11           ` Roland McGrath
2011-07-27  1:06             ` H.J. Lu
2011-07-27  6:31               ` Roland McGrath
2011-07-27 20:59                 ` Roland McGrath
2011-07-27 21:49                   ` 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=CAMe9rOpv+0noPiDa6fa+2oCx+j23xew1ntkHiDzUyoy04ZOXgQ@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=mcgrathr@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).