https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659

            Bug ID: 94659
           Summary: Missing symbol with LTO and target_clones
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yyc1992 at gmail dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This is basically the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732 except now it only happens
with LTO enabled.

It seems that if a function with `target_clones` attribute isn't used in the
final library and if LTO is enabled, the function will be missing from the
resulting library. Only the `.resolver` symbol appears.

The test code is

```
// b.c

__attribute__((target_clones("default,avx")))
int f1()
{
    return 2;
}
```

when compiled with `gcc -g -flto -O3 -fPIC b.c -shared -o libb-lto.so`, the
exported symbols available are,

```
$ objdump -T libb-lto.so

libb-lto.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000  w   D  *UND*  0000000000000000             
_ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000             
_ITM_registerTMCloneTable
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000001730 g    DF .text  000000000000002b  Base        f1.resolver
```

Compared to the output lilbrary from `gcc -g -O3 -fPIC b.c -shared -o libb.so`

```
$ objdump -T libb.so

libb.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000  w   D  *UND*  0000000000000000             
_ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000             
_ITM_registerTMCloneTable
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000001730  w   DF .text  000000000000002b  Base        f1.resolver
0000000000001730 g   iD  .text  000000000000002b  Base        f1
```

The exported symbol has the wrong name for the LTO version. `dlsym` result
confirms the difference.

If the function is used somewhere else in the library, the resulting symbol
will then looks the same as the non-LTO version.

Reply via email to