https://sourceware.org/bugzilla/show_bug.cgi?id=34570
Bug ID: 34570
Summary: ld.bfd always keeps common symbol from native object
Product: binutils
Version: 2.46.1
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: npopov at redhat dot com
Target Milestone: ---
This issue came up when porting tests for the LLVMgold.so plugin from ld.gold
to ld.bfd.
common-small.ll:
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@a = common global i32 0, align 4
common-big.ll:
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@a = common global i64 0, align 8
repro.sh:
llc common-small.ll -o common-small.o -filetype=obj # native
llvm-as common-big.ll -o common-big.o # IR
ld.bfd -m elf_x86_64 -plugin=/usr/lib64/LLVMgold.so \
common-big.o common-small.o -o result.o
objdump -t result.o
Results in:
0000000000401000 g O .bss 0000000000000004 a
That is, the common symbol a has size 4.
It appears that unlike ld.gold, ld.bfd always picks the symbol from the native
object as the prevailing definition, even though the one in the IR object is
larger.
ld.bfd reports LDPR_RESOLVED_EXEC for the symbol, while ld.gold reports
LDPR_PREVAILING_DEF.
--
You are receiving this mail because:
You are on the CC list for the bug.
