[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/16345] ld emits errors on .eh_frame from partial linking

From: stilor at att dot net
Subject: [Bug ld/16345] ld emits errors on .eh_frame from partial linking
Date: Fri, 20 Dec 2013 20:36:34 +0000


--- Comment #3 from Alexey Neyman <stilor at att dot net> ---
Well, we've been using partial linking to isolate module interfaces. One of the
modules is CPU support - which includes the start-up code for the kernel.
Naturally, this start up code was put into the .init section.

Our code in .init does not have .eh_frame contributions, but the mere presence
of the .init section in the object file already makes `ld -r` output unsorted
relocations. You can see that by substituting qq2.s in the test case with:

.section .init,"ax",@progbits
/* empty .init section */
.globl baz
baz: .cfi_startproc; ret; .cfi_endproc

Now, it is probably possible for us to rename the .init section to, say,
.text.startup - but are there any guarantees that `ld -r` is not going to mess
up the output relocations in that case?

Also, the quote from LSB talks about semantical differences between .text and
.init. Is there any technical reason not to allow `ld -r` on files with .init?
Perhaps, it would be better to accept such files with unordered relocations on
input and/or order the relocations on output?

You are receiving this mail because:
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]