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: [GOLD] advice on powerpc64 .opd handling


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


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