[Bug ld/17550] New: Section groups (comdat/linkonce) create undefined symbols unnecessarily

[srk31 at srcf dot ucam.org]

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.