This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sparc-vxworks support


From: Richard Sandiford <richard@codesourcery.com>
Date: Tue, 07 Mar 2006 10:17:46 +0000

> The main one is the PLT layout, which is very different from the other
> SPARC ABIs.  In fact, it's so different that it doesn't really fit the
> build_plt_entry callback mechanism used in elfxx-sparc.c: as well as the
> PLT entry itself, we need a .got.plt entry, and (for executables) a
> bunch of .rela.plt.unloaded relocations.  Also, the .rela.plt relocation
> refers to the .got.plt entry, not to the .plt itself.  I've therefore
> bypassed the build_plt_entry stuff and handled VxWorks directly in
> finish_dynamic_symbol.
> 
> Also, there are now 4 possible sizes of PLT header and 3 possible
> sizes of PLT entry, so I've added link_hash_table fields for them.
> The VxWorks choice depends on whether we're generating a shared
> object or not, so the fields are initialised in create_dynamic_sections
> (the place where we initialise splt).  For consistency, I moved the
> build_plt_entry initialisation there too; the hook isn't needed
> before then.
> 
> Tested on sparc-vxworks, sparc-linux-gnu, sparc64-linux-gnu and
> sparc-sun-solaris2.6 (a 32-bit-only target).  OK to install?

This looks mostly fine to me.

In fact, when and if I ever get around to doing a secure PLT
format for Sparc it will probably look something similar to
what this VxWorks PLT scheme is doing.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]