This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: PR ld/4590: String merging breaks ia64 linker
"H. J. Lu" <hjl@lucon.org> writes:
> On Mon, Jun 11, 2007 at 10:37:45AM +0200, Andreas Schwab wrote:
>> "H. J. Lu" <hjl@lucon.org> writes:
>>
>> > Please provide me a testcase to show it.
>>
>> This is a better one, it tests more cases:
>>
>> .section .rodata.str1.8,"aMS", 1
>> .LC1: .string "foo"
>> .LC2: .string "foo"
>> .LC3: .string "bar"
>> .LC4: .string "bar"
>> .LC5: .string "baz"
>> .LC6: .string "baz"
>> .section .data.rel.local,"aw"
>> .quad .LC2
>> .quad .LC4
>> .quad .LC5
>> .section .rodata,"a"
>> .LC7: .string "mumble"
>> .balign 8
>> .space 0x400000
>> .text
>> addl r12=@ltoffx(.LC1),r1 ;;
>> addl r12=@ltoffx(.LC3),r1 ;;
>> addl r12=@ltoffx(.LC6),r1 ;;
>> addl r12=@ltoffx(.LC7),r1 ;;
>>
>
> Could you please try this patch?
Here's another testcase:
.section .rodata.str1.8,"aMS", 1
.LC1: .string "foo"
.LC2: .string "foo"
.LC3: .string "bar"
.LC4: .string "bar"
.LC5: .string "bar"
.LC6: .string "bar"
.LC7: .string "baz"
.LC8: .string "baz"
.section .data.rel.local,"aw"
.quad .LC2
.quad .LC4
.quad .LC6
.quad .LC7
.section .rodata,"a"
.LC9: .string "mumble"
.balign 8
.space 0x400000
.text
addl r12=@ltoffx(.LC1),r1 ;;
addl r12=@ltoffx(.LC3),r1 ;;
addl r12=@ltoffx(.LC5),r1 ;;
addl r12=@ltoffx(.LC8),r1 ;;
addl r12=@ltoffx(.LC9),r1 ;;
> @@ -2290,20 +2310,39 @@ sort_dyn_sym_info (struct elfNN_ia64_dyn
> if (len == 1 && dup < count)
> {
> /* If we only move 1 element, we combine it with the next
> - one. Find the next different one. */
> + one. We will keep DUP instead of SRC. Make sure that
> + DUP has a valid got_offset. */
It's always info[src] that is kept. But inside this loop it's the last
of a run of identical addends, not the first one. Another problem is
that there may be several entries with got_offset == -1, and another
batch of entries with got_offset != -1, all with the same addend. It's
not immediately clear which of them to pick. Ideally, all this merging
should already happen before relaxing, so that we don't allocate those
extra got entries and NONE relocations.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."