This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD] advice on powerpc64 .opd handling
- From: Ian Lance Taylor <iant at google dot com>
- To: Ian Lance Taylor <iant at google dot com>, Cary Coutant <ccoutant at google dot com>, binutils at sourceware dot org, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Wed, 15 Aug 2012 15:39:20 -0700
- Subject: Re: [GOLD] advice on powerpc64 .opd handling
- References: <20120815024622.GK3947@bubble.grove.modra.org>
On Tue, Aug 14, 2012 at 7:46 PM, Alan Modra <amodra@gmail.com> wrote:
> Hi Ian, Cary,
> I'd like some guidance on how I should implement .opd entry lookup
> for PowerPC64. The problem is this:
>
> - A PowerPC64 function symbol points at a function descriptor in the
> .opd section.
> - Relocations on branch and call insns reference the function symbol.
> For functions that resolve locally, we want to branch to the
> function code entry point, necessitating a read of the function
> descriptor in the .opd section.
> - .opd section contents are useless until after relocation. (.opd
> could be nobits in most relocatable object files.)
>
> gold will need to evaluate .opd entries during --gc-sections
> processing (to find the code section to mark), when creating call
> stubs (for analysis of code section relocs to determinde whether a toc
> adjusting stub is needed), and when performing final relocation.
> This of course will happen for any section that might contain a direct
> function call, ie. all code sections, but the .opd section involved
> will always be the one in the same object file as the code section.
> Another twist is that in the future I'd like to relax .opd for
> --gc-sections, removing entries for functions in discarded sections.
>
> In BFD, elf64-ppc.c:opd_entry_value I implement OPD entry lookup by
> doing a binary search over .opd relocs to find the one on the
> particular OPD entry of interest, then use that reloc symbol/addend to
> find the code section and offset.
>
> Should I do the same in gold or would some other approach be better?
> (I'm still discovering when and where various things happen in gold,
> but I'm thinking a better approach might be to build up .opd entry
> info in a vector during reloc scan. And somehow ensure .opd relocs
> are scanned before any other section..)
I don't really know the answer here. It sounds like what you need are
not the contents of the .opd section itself, but the contents of the
.rela.opd section. gold will read all the relocs before it does
anything with them. Perhaps you can define a do_read_relocs function
in your Powerpc_relobj class that calls the Sized_relobj_file
do_read_relocs routine, then looks through the Section_relocs to find
the .opd relocs, then builds whatever data structure you need out of
that.
Ian