This is the mail archive of the
mailing list for the binutils project.
Re: PCREL preinit/init/fini arrays?
- From: Alan Modra <amodra at gmail dot com>
- To: Matt Thomas <matt at 3am-software dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 19 Aug 2014 11:22:17 +0930
- Subject: Re: PCREL preinit/init/fini arrays?
- Authentication-results: sourceware.org; auth=none
- References: <9D2DE305-CF39-4A2C-A7CB-744F633D8A04 at 3am-software dot com>
On Mon, Aug 18, 2014 at 01:47:28PM -0700, Matt Thomas wrote:
> I'm adding support for a few new architectures to NetBSD I'm planning on using
> the preinit/init/fini arrays rather than .init/.fini/.ctors/.dtors.
> Rather than emitting relocation entries for the arrays, I'm thinking about making
> each entry PC-relative to itself. This would allow them to move to the .text
> PT_LOAD program section since they could be read-only.
Only if the pointers in .init_array etc. are always local. Usually
the case, but I don't think anything in the ELF gABI precludes
.init_array from holding pointers to global functions, which would
need dynamic relocations in a shared library.
In any case, .init_array is already read-only after relocation, so
moving to a fully read-only section doesn't gain you much.
> Having to compute the
> address of each entry shouldn't be any more expensive than doing the R_RELATIVE
> relocation that the PCREL eliminates.
Right, it's likely to be quite a lot cheaper than a dynamic relocation.
> I can't think of any downsides, except for getting binutils to support it, but
> maybe I'm overlooking something. Am I? :)
The biggest downside is that the ELF gABI says .init_array
etc. contain arrays of function pointers. So you're talking about
modifying the gABI if you want to use the same section names, or using
different section names.
Australia Development Lab, IBM