Bug 28622

Summary:	Common symbol version information wrong in ld.bfd-linked library
Product:	binutils	Reporter:	Timm Bäder <tbaeder>
Component:	ld	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED FIXED
Severity:	normal	CC:	nickc
Priority:	P2
Version:	2.35
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Timm Bäder 2021-11-24 14:15:54 UTC

Using this reproducer script:

#!/bin/sh

echo '.globl foo' > foo.s
echo '.comm foo,1,1' >> foo.s

# foo version in lib1.so is Base
gcc -shared -fPIC -o lib1.so foo.s
objdump -T lib1.so | grep foo


# foo's version in lib2.so is now ""
gcc -shared -fPIC -o lib2.so -L. -l1 foo.s
objdump -T lib2.so | grep foo



foo's version in lib1.so ends up being "Base". This reproducible with ld.bfd, lld and gold.

However, foo's version in lib2.so ends up being "" (no version information given). That *only* reproduces with ld.bfd and not with lld or gold.
Using the latter two, foo's version is Base in lib2.so as well.

Comment 1 Alan Modra 2021-11-24 22:59:58 UTC

This does not reproduce for me on any upstream version of binutils I tried.

Comment 2 Timm Bäder 2021-11-25 06:45:21 UTC

Ok, with current ld.bfd from the master branch, I get

lib1.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000  w   D  *UND*	0000000000000000  Base        _ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*	0000000000000000  Base        __gmon_start__
0000000000000000  w   D  *UND*	0000000000000000  Base        _ITM_registerTMCloneTable
0000000000000000  w   DF *UND*	0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000004019 g    DO .bss	0000000000000001  Base        foo


for the lib1.so. With the 2.35.2 installed on my system, the first three symbols had no version information.

And the output for lib2.so is exactly the same. Looks like this is already fixed.

Comment 3 Timm Bäder 2021-12-08 06:20:37 UTC

Got further confirmation from LLD upstream that everything is as it should be with newer binutils. Thanks.

Comment 4 Nick Clifton 2021-12-09 09:09:01 UTC

The problem was fixed by Alan's patch for PR 26002..