public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Including rel* sections in an ELF64 executable
@ 2000-01-26 14:55 Bharadwaj Yadavalli
  2000-01-26 15:04 ` Ian Lance Taylor
  0 siblings, 1 reply; 2+ messages in thread
From: Bharadwaj Yadavalli @ 2000-01-26 14:55 UTC (permalink / raw)
  To: binutils

Hi,

I had sent personal mails to a couple of people 
who might be active developers of this list with
questions regarding the subject line. They have
kindly answered my questions. One of them had
suggested that I ask questions on this mailing
lits. Not wishing to pester them with follow-up 
questions, I am asking them on this list. I will
be glad if someone can kindly help me out.

I am working on a Linux/Alpha box and my ld version 
is ld version 2.9.5 (with BFD 2.9.5.0.13).

I am interested in emitting relocation information
in the output of the linker. This information is
needed in post-link optimization or binary manipulation
tools that for example modify code in text section.

After reading and experimenting, I formed a mental 
model of the linking process as consisting of three 
conceptual phases:

1. Read the files to be linked and form an internal
   representation (rooted in BFD) of their contents.
2. Perform resolve references and preform any patch-ups
   needed on the internal representation. 
3. Emit an output according to the linker scripts.

I started visualizing the linker script as a "filter" that
controls the contents of the linker output.

This model makes the job of getting relocation records
emitted in a linker output as simple as writing a linker
script. However, there seems to be some gap in my model as I
am unable to explain the following observations.

The script /usr/lib/ldscripts/elf64alpha.xr has section
commands to emit .rel* sections in the linker output and
sure enough I can see these sections in the output. The
script /usr/lib/ldscripts/elf64alpha.x also has section
commands to emit .rel* sections in the linker output and the
linker doesn't emit them !! I can not see anything else in
/usr/lib/ldscripts/elf64alpha.xr that instructs the linker
to emit the relocation information nor can I see anything in
/usr/lib/ldscripts/elf64alpha.x that instructs it to discard
the information. 

Does the linker use output rules other than those specified
in the linker script? It was pointed out to me that the
linker scripts simply direct the placement of the output
sections. But what is it that triggers the discarding
of local relocation information, in say a .o file, when 
executing /usr/lib/ldscripts/elf64alpha.x and retention of
the same when executing /usr/lib/ldscripts/elf64alpha.xr?

Thanks for your attention and responses.

Bharadwaj

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

* Re: Including rel* sections in an ELF64 executable
  2000-01-26 14:55 Including rel* sections in an ELF64 executable Bharadwaj Yadavalli
@ 2000-01-26 15:04 ` Ian Lance Taylor
  0 siblings, 0 replies; 2+ messages in thread
From: Ian Lance Taylor @ 2000-01-26 15:04 UTC (permalink / raw)
  To: sby; +Cc: binutils

   From: Bharadwaj Yadavalli <sby@ives.lkg.dec.com>
   Date: Wed, 26 Jan 2000 17:55:19 -0500 (EST)

   Does the linker use output rules other than those specified
   in the linker script? It was pointed out to me that the
   linker scripts simply direct the placement of the output
   sections. But what is it that triggers the discarding
   of local relocation information, in say a .o file, when 
   executing /usr/lib/ldscripts/elf64alpha.x and retention of
   the same when executing /usr/lib/ldscripts/elf64alpha.xr?

The linker uses the .xr linker script when the -r option is used.  The
-r option is what controls whether to retain relocation information.

Ian

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

end of thread, other threads:[~2000-01-26 15:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-26 14:55 Including rel* sections in an ELF64 executable Bharadwaj Yadavalli
2000-01-26 15:04 ` Ian Lance Taylor

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).