Hi,
I'm having a linking problem with gcc and ld (gcc 3.3.5-20050130 and GNU ld
version 2.15.92.0.2 20040927): ld has the following weird behavior that I don't
manage to disable.
I'm using a ld script for ordering sections in a particular way (and defining
symbols between these sections), more specifically, I place the rodata section
of one of the object files after the rodata section of the other object files.
The relevant part of the ld script looks something like:
.rodata :
{
start_one = .;
file1.o(.rodata .rodata.* .gnu.linkonce.r.*)
end_one = .;
start_others = .;
*(.rodata .rodata.* .gnu.linkonce.r.*)
end_others = .;
}
There is identical data in the .rodata.str1.1 sections of file1.o and, say
file2.o. For example, the assembly output obtained with the -save-temps switch
looks like:
file1.s:
(...)
.section .rodata.str1.1
.LC11:
.string "before1"
.LC12:
.string "text"
.LC13:
.string "after1"
(...)
file2.s:
(...)
.section .rodata.str1.1
.LC53:
.string "before2"
.LC54:
.string "text"
.LC55:
.string "after2"
(...)
The problem is, that ld seems to detect this case and only outputs one instance
of this data, either the one in file1.o or the one in file2.o (never mind,
let's say it keeps only the one of file1.o). This means that it removes the
instance in file2.o (ie it removes the string "text" in section .rodata.str1.1
of file2.o) and relocates references to the data in file2.o (ie references to
.LC54 in file2.o) to the data kept in file1.o (ie to .LC12 in file1.o). (cf.
end of this mail if this is not clear enough). I checked this by examining the
elf output. What I would like is that ld output the sections without doing this
sort of guesses. I would like to get my sections unchanged, and if some data
appears 10 times in 10 input object files, I want this data to appear 10 times
in the output in the corresponding sections at the right places. I looked for
switches doing this but didn't find them.
I have to say that I found this sort of section modifications a little
surprising. In my particular case (admittedly not common, but I won't elaborate
on this now, this is not relevant), the program does not work as a result. But
I imagine that it could have consequences on more standard applications: for
example, I think this could change data alignment ; or remove elements in
sections used as an array of data, as this is done for example in the kernel
(cf section .initcall.init). I'm not an expert, that's just a guess.
I searched on the internet, and found this behavior might be known as
"relaxing", but the ld man page I have seems to use this word for something
else, and the --no-relax option is not recognized. So I didn't find a solution
to inhibit this behavior.
I would greatly appreciate if someone could help. BTW, I use linux on i686, and
the same linker script worked perfectly well with the previous version of ld I
had (unfortunately, I don't remember which version it was, maybe a
3- to 5-year-old version). If that's the only solution, I would have to
downgrade to this previous ld version, but this would really be a pitty!...
Thanks in advance!
Remy Bruno
Further description of the example:
After compilation, we get the following binary data:
in sections .rodata.str1.1:
file1.o:
section .rodata.str1.1:
(...)before1\000text\000after1\000(...)
section .text:
unrelocated references to .LC12, corresponding to "text"
file2.o:
section .rodata.str1.1:
(...)before2\000text\000after2\000(...)
section .text:
unrelocated references to .LC54, corresponding to "text"
After linking, we get the following binary data
section .rodata.str1.1:
(...)before1\000text\000after1\000(...) [corresponds to file1.o]
(...)before2\000after2\000(...) [corresponds to file2.o with "text" removed]
section .text:
references to .LC12 relocated as expected within ex-file1.o
references to .LC54 in ex-file2.o relocated to "text" corresponding to
ex-file1.o
What I would like:
section .rodata.str1.1:
(...)before1\000text\000after1\000(...) [corresponds to file1.o]
(...)before2\000text\000after2\000(...) [corresponds to file2.o]
section .text:
references to .LC12 relocated as expected within ex-file1.o
references to .LC54 relocated as expected within ex-file2.o
