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