public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [GOLD] advice on powerpc64 .opd handling
@ 2012-08-15  4:04 Alan Modra
  2012-08-16  9:24 ` Ian Lance Taylor
  0 siblings, 1 reply; 9+ messages in thread
From: Alan Modra @ 2012-08-15  4:04 UTC (permalink / raw)
  To: Ian Lance Taylor, Cary Coutant; +Cc: binutils, David Edelsohn

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-08-18 11:13 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-15  4:04 [GOLD] advice on powerpc64 .opd handling Alan Modra
2012-08-16  9:24 ` Ian Lance Taylor
2012-08-16 13:53   ` Alan Modra
2012-08-17  5:28     ` Ian Lance Taylor
2012-08-17  8:11       ` Alan Modra
2012-08-17 14:36         ` Ian Lance Taylor
2012-08-18  1:45           ` Alan Modra
2012-08-18 11:13             ` Ian Lance Taylor
2012-08-18 12:49               ` Alan Modra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).