https://sourceware.org/bugzilla/show_bug.cgi?id=17550
Bug ID: 17550
Summary: Section groups (comdat/linkonce) create undefined
symbols unnecessarily
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: srk31 at srcf dot ucam.org
Created attachment 7894
--> https://sourceware.org/bugzilla/attachment.cgi?id=7894&action=edit
Code to reproduce the (believed) bug, and makefile
I noticed a behaviour which surprised me, and which is problematic in my use
case, in how ELF section groups work when doing COMDAT linking. Suppose that a
given section group has two instances, like so. (Showing the source files that
I used to generate the linker inputs; tarball with makefile attached.)
$ cat file1.c
int x __attribute__((section (".data.x.test, \"awG\", @progbits, x.test,
comdat#")));
extern int x_alias __attribute__((section (".data.x.test, \"awG\", @progbits,
x.test, comdat#"),alias("x")));
$ cat file2.c
int x __attribute__((section (".data.x.test, \"awG\", @progbits, x.test,
comdat#")));
(I made the second symbol an alias because that's the scenario in which I
discovered this behaviour... but it doesn't seem to matter.)
We link them together, and depending on the link order, we get one or other
copy of the section.
$ ld -r -o "files-ok.o" file1.o file2.o # ld takes file1's section
$ ld -r -o "files-with-und.o" file2.o file1.o # ld takes file2's section
What surprised me is that in the case where a symbol definition is discarded,
we also get an undefined symbol in the output.
$ objdump -t files-with-und.o
files-with-und.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l d .group 0000000000000000 .group
0000000000000000 l d .text 0000000000000000 .text
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 l d .data.x.test 0000000000000000 .data.x.test
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l d .comment 0000000000000000 .comment
0000000000000000 l d .note.GNU-stack 0000000000000000
.note.GNU-stack
0000000000000000 l df *ABS* 0000000000000000 file2.c
0000000000000000 l .group 0000000000000000 x.test
0000000000000000 l df *ABS* 0000000000000000 file1.c
0000000000000000 g O .data.x.test 0000000000000004 x
0000000000000000 O *UND* 0000000000000000 x_alias
The bug is that I believe this undefined symbol shouldn't be present. I would
expect an undefined symbol to be created only if there is a reference *to* the
discarded symbol from elsewhere within the linker input. Otherwise it seems to
serve no purpose. (The discarded definition can be harmless, since it might be
effectively an "optional extra" of the particular COMDAT section copy that was
discarded. This is the case in my scenario.)
Moreover, leaving it in the symtab creates unnecessary problems later. Consider
linking files-with-und.o into a shared library which uses x but doesn't use
x_alias. Dynamic linking against this library will fail, even though nobody
cares that x_alias is absent.
Although I can get the effect I want with objcopy --strip-unneeded, that might
remove symbols that really should be there. It seems better to push this
behaviour into the section group handling, if it doesn't break anything.
I can work on a patch for this if necessary, but first I'd be glad to know
whether my reading of this behaviour is correct.
(An alternative behaviour that would work for me would be to merge aliases
across comdat linking. But this seems a bit hacky because ELF doesn't have a
concept of "alias" per se. And it might create "multiple definition" errors
where there previously weren't any.)
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
