This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[GOLD] advice on powerpc64 .opd handling
- From: Alan Modra <amodra at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>, Cary Coutant <ccoutant at google dot com>
- Cc: binutils at sourceware dot org, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Wed, 15 Aug 2012 12:16:22 +0930
- Subject: [GOLD] advice on powerpc64 .opd handling
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..)
--
Alan Modra
Australia Development Lab, IBM