[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