Bug 25708 - nm -D doesn't display symbol version for dynamic symbols
Summary: nm -D doesn't display symbol version for dynamic symbols
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.35
: P2 normal
Target Milestone: 2.35
Assignee: Not yet assigned to anyone
URL: https://sourceware.org/pipermail/binu...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-22 11:46 UTC by H.J. Lu
Modified: 2020-08-07 15:39 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2020-03-22 11:46:38 UTC
[hjl@gnu-cfl-2 pr13195]$ cat x.s
	.section .text.new_foo,"ax",%progbits
	.globl	new_foo
	.type	new_foo, %function
new_foo:
	call foo
	call bar
	.symver new_foo,foo@@VERS_2.0
[hjl@gnu-cfl-2 pr13195]$ cat x.t
VERS_2.0 {
global:
  foo;
local:
  *;
};
[hjl@gnu-cfl-2 pr13195]$ make x.so
ld -shared --gc-sections -shared -version-script x.t --hash-style=gnu -o x.so x.o
[hjl@gnu-cfl-2 pr13195]$  /export/build/gnu/tools-build/binutils/build-x86_64-linux/binutils/nm-new -D x.so 
                 U bar
0000000000001030 T foo
0000000000000000 A VERS_2.0
[hjl@gnu-cfl-2 pr13195]$  /export/build/gnu/tools-build/binutils/build-x86_64-linux/binutils/objdump --dynamic-syms x.so

x.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000      D  *UND*	0000000000000000              bar
0000000000000000 g    DO *ABS*	0000000000000000  VERS_2.0    VERS_2.0
0000000000001030 g    DF .text	0000000000000000  VERS_2.0    foo


[hjl@gnu-cfl-2 pr13195]$
Comment 1 H.J. Lu 2020-03-22 12:36:11 UTC
A patch is posted at

https://sourceware.org/pipermail/binutils/2020-March/110333.html
Comment 2 cvs-commit@gcc.gnu.org 2020-03-24 11:29:16 UTC
The master branch has been updated by H.J. Lu <hjl@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7e6e972f74aeac0ebdbd95a7f905d871cd2581de

commit 7e6e972f74aeac0ebdbd95a7f905d871cd2581de
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Mar 24 04:23:11 2020 -0700

    bfd: Display symbol version for nm -D
    
    Extend _bfd_elf_get_symbol_version_string for nm -D to display symbol
    version.  _bfd_elf_get_symbol_version_name is added to avoid updating
    all XXX_get_symbol_version_string functions.
    
    bfd/
    
            PR binutils/25708
            * elf-bfd.h (_bfd_elf_get_symbol_version_name): New.
            * elf.c (_bfd_elf_get_symbol_version_name): New function.  Based
            on the previous _bfd_elf_get_symbol_version_string.
            (_bfd_elf_get_symbol_version_string): Use it.
    
    binutils/
    
            PR binutils/25708
            * nm.c (SYM_NAME): Removed.
            (print_symname): Add a pointer to struct extended_symbol_info
            argument.  Call _bfd_elf_get_symbol_version_name to get symbol
            version.
            (print_symdef_entry): Pass NULL to print_symname.
            (print_symbol_info_bsd): Update call to print_symname.
            (print_symbol_info_sysv): Likewise.
            (print_symbol_info_posix): Likewise.
    
    ld/
    
            PR binutils/25708
            * testsuite/ld-elf/pr25708.d: New file.
Comment 3 H.J. Lu 2020-03-24 12:03:04 UTC
Fixed for 2.35.
Comment 4 Nick Clifton 2020-03-24 17:13:13 UTC
Hi H.J.

  Oops - I have just noticed some build failures from non-ELF based
  targets, eg alpha-dec-vms and i386=pc-go32:

    /bin/ld: nm.o: in function `print_symname':
    binutils/nm.c:420: undefined reference to `_bfd_elf_get_symbol_version_name'

  Please could you have a look into this.

Cheers
  Nick
Comment 5 H.J. Lu 2020-03-24 17:52:15 UTC
(In reply to Nick Clifton from comment #4)
> Hi H.J.
> 
>   Oops - I have just noticed some build failures from non-ELF based
>   targets, eg alpha-dec-vms and i386=pc-go32:
> 
>     /bin/ld: nm.o: in function `print_symname':
>     binutils/nm.c:420: undefined reference to
> `_bfd_elf_get_symbol_version_name'
> 
>   Please could you have a look into this.

Here is the patch:

https://sourceware.org/pipermail/binutils/2020-March/110366.html
Comment 6 cvs-commit@gcc.gnu.org 2020-03-24 22:38:26 UTC
The master branch has been updated by H.J. Lu <hjl@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1081065c519d1bfc3847bf4b0a0ce4bc3224bcd3

commit 1081065c519d1bfc3847bf4b0a0ce4bc3224bcd3
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Mar 24 15:37:14 2020 -0700

    bfd: Add a bfd_boolean argument to bfd_get_symbol_version_string
    
    We can't call _bfd_elf_get_symbol_version_name from nm.c since it isn't
    available for all target configurations.  This patch add a bfd_boolean
    argument to bfd_get_symbol_version_string instead.
    
    bfd/
    
            PR binutils/25708
            * elf-bfd.h (_bfd_elf_get_symbol_version_name): Renamed to ...
            (_bfd_elf_get_symbol_version_string): This.
            * elf.c (_bfd_elf_get_symbol_version_name): Renamed to ...
            (_bfd_elf_get_symbol_version_string): This.
            (bfd_elf_print_symbol): Pass TRUE to
            _bfd_elf_get_symbol_version_string.
            * libbfd-in.h (_bfd_nosymbols_get_symbol_version_string): Add a
            bfd_boolean argument.
            * syms.c (_bfd_nosymbols_get_symbol_version_string): Likewise.
            * targets.c  (_bfd_get_symbol_version_string): Likewise.
            (bfd_get_symbol_version_string): Likewise.
            * bfd-in2.h: Regenerated.
    
    binutils/
    
            PR binutils/25708
            * nm.c (print_symname): Replace _bfd_elf_get_symbol_version_name
            with bfd_get_symbol_version_string.
            (print_symbo): Pass TRUE to bfd_get_symbol_version_string.
            * objdump.c (objdump_print_symname): Likewise.
Comment 7 H.J. Lu 2020-03-24 22:49:27 UTC
Fixed
Comment 8 Michael Matz 2020-08-07 14:08:37 UTC
This breaks at least the perf build from linux kernel 5.7 as nm is used to construct a symbol list for feeding into ld, which now contains '@' characters
which aren't liked by ld (of course).  See e.g.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887397

Is it really a good idea to change the output format of basic tools that might be
used in machine processing context?  (And I note there doesn't seem to be an
cmdline option to get the old behaviour back, so fixing the problem now entails
further massaging of nm output to cut off /@.*/ )
Comment 9 H.J. Lu 2020-08-07 14:41:47 UTC
(In reply to Michael Matz from comment #8)
> This breaks at least the perf build from linux kernel 5.7 as nm is used to
> construct a symbol list for feeding into ld, which now contains '@'
> characters
> which aren't liked by ld (of course).  See e.g.
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887397
> 
> Is it really a good idea to change the output format of basic tools that
> might be
> used in machine processing context?  (And I note there doesn't seem to be an
> cmdline option to get the old behaviour back, so fixing the problem now
> entails
> further massaging of nm output to cut off /@.*/ )

Is this PR 26302?  A patch is at

https://sourceware.org/pipermail/binutils/2020-July/112556.html
Comment 10 Michael Matz 2020-08-07 15:27:24 UTC
(In reply to H.J. Lu from comment #9)
> > 
> > Is it really a good idea to change the output format of basic tools that
> > might be
> > used in machine processing context?  (And I note there doesn't seem to be an
> > cmdline option to get the old behaviour back, so fixing the problem now
> > entails
> > further massaging of nm output to cut off /@.*/ )
> 
> Is this PR 26302?  A patch is at

No.  perf does the moral equivalent of:

% ( echo "{"; nm -D input.so | awk '{print $1";"}'; echo "}" ) > thelist
% ld ... --dynamic-list=thelist

Of course 'thelist' now contains @ characters, because nm -D shows symversions,
and that's what ld is complaining about:

thelist:2: ignoring invalid character `@' in script
thelist:2: syntax error in dynamic list
collect2: error: ld returned 1 exit status

The build system of simply isn't prepared to deal with these symversions.
So one of several things need to happen:
a) nm -D doesn't print symversions, unless explicitely requested
b) nm -D continues to print them, but with an option to disable them
c) perf Makefile is changed to filter out any /@.*/ in the nm output

I'm not sure how widespread such usage of nm is, and hence how often fix (c)
would have to be applied in the wild.  Fixing such packages would at least
be easier if nm had an option to disable printing them (i.e. (b)).  But maybe
it's best to not change traditional behaviour of nm at all, i.e. change (a),
and revert to not printing symversions by default.

I don't know what's best.
Comment 11 H.J. Lu 2020-08-07 15:39:15 UTC
(In reply to Michael Matz from comment #10)
> (In reply to H.J. Lu from comment #9)
> > > 
> > > Is it really a good idea to change the output format of basic tools that
> > > might be
> > > used in machine processing context?  (And I note there doesn't seem to be an
> > > cmdline option to get the old behaviour back, so fixing the problem now
> > > entails
> > > further massaging of nm output to cut off /@.*/ )
> > 
> > Is this PR 26302?  A patch is at
> 
> No.  perf does the moral equivalent of:
> 
> % ( echo "{"; nm -D input.so | awk '{print $1";"}'; echo "}" ) > thelist
> % ld ... --dynamic-list=thelist
> 

Please a new bug report with a small testcase.