[PATCH] elf: Keep only one '@' for undefined versioned symbols
Alan Modra
amodra@gmail.com
Fri Jul 30 00:44:18 GMT 2021
On Thu, Jul 29, 2021 at 01:13:35PM -0600, Tom Tromey wrote:
> >>>>> ">" == H J Lu via Binutils <binutils@sourceware.org> writes:
>
> >> The symbol string table in the .symtab section is optional. Keep only
> >> one '@' for undefined versioned symbols, which are defined in shared
> >> objects, in the symbol string table. Update "nm -D" to display only
> >> one '@' for undefined versioned symbols.
>
> This change broke an Ada test case for gdb. It's in the internal
> AdaCore test suite, but I can share it if it's important. It only fails
> for PPC and AArch64 targets.
>
> The test case builds a .so and an executable. A function .so raises an
> exception. In Ada this amounts to something like "throw
> &global_variable".
>
> The symbol in the library is like so:
>
> $ nm lib/libsal.so |grep some_kind
> 00020004 D some_package__some_kind_of_error
> 00001eb0 R some_package__some_kind_of_errorE
>
> and in the executable:
>
> $ nm bin/qc04_049 |grep some_kind
> 10020224 B some_package__some_kind_of_error@SYMS
>
> Note the single "@".
>
> There's a copy reloc for this symbol:
>
> $ readelf -r bin/qc04_049 | grep some
> 10020224 00003713 R_PPC_COPY 10020224 some_package__some_kin@SYMS + 0
The first thing that jumps out at me from your description of the
problem is that some_package__some_kind_of_error@SYMS in the
executable is in fact a defined symbol, whereas HJ's log for the
change that removed an "@" from the symbol name talks about undefined
symbols. We very likely have a linker bug.
However, I'd like to see the result of
nm -D lib/libsal.so | grep some_kind
before making too many more comments. The dynamic symbols are the
ones that matter.
--
Alan Modra
Australia Development Lab, IBM
More information about the Binutils
mailing list