[Bug gold/16794] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections

[rprichard at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16794

--- Comment #8 from Ryan Prichard <rprichard at google dot com> ---
> In a string merge section, sym+offset is valid only for offset within the 
> string at sym.

The GNU assembler is apparently willing to use section+offset to identify a
mergeable string for some relocations (maybe non-PC-relative / non-GOT
relocations?).

e.g.:

extern int puts(const char*);
void func() { puts("foo1"); }
void func2() { puts("foo2"); }

If I compile with "gcc -m32 -fno-pie -O2 -c", I see these relocations in the
object file:

00000004  00000501 R_386_32               00000000   .rodata.str1.1
00000024  00000501 R_386_32               00000000   .rodata.str1.1

The assembly references local symbols (.LC0 and .LC1) within .rodata.str1.1,
but the assembler has omitted the symbols in favor of relocations to the
section itself. The second REL relocation has an addend of 5 stored inside the
.text content.

gold appears to handle merging section+offset relocations fine when they're
R_386_32, but not when they're R_386_GOTOFF. Both relocation types are
documented in the psABI as allowing an addend.

Also:

> I looked at the testcase briefly, and it looked like test.o contained two 
> strings, "xabcde" and "abcde". ld.bfd merged the two, but ld.gold didn't. I 
> used "GNU gold (GNU Binutils for Debian 2.31.1) 1.16".

gold's overlapping string merging happens when -O2 is passed to ld.gold, and I
hadn't passed -O2. When I do, I see the reported/unwanted ld.gold behavior.

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