Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1365418 - Symbol __gmon_start__ missing on ppc64 and s390x
Summary: Symbol __gmon_start__ missing on ppc64 and s390x
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: binutils
Version: DTS 6.0 RHEL 7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: alpha
: 6.0
Assignee: Nick Clifton
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-09 08:33 UTC by Miloš Prchlík
Modified: 2016-08-16 21:36 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-10 11:06:05 UTC


Attachments (Terms of Use)

Description Miloš Prchlík 2016-08-09 08:33:14 UTC
Description of problem:

This may very well be an expected behavior, however I'd rather have it re-checked by those who are more experienced. Feel free to close it as NOTABUG if what I observe is correct behavior.


DTS-6 comes to other arches, not just x86_64. One of our tests includes the following:


[root@ibm-p8-04-lp5 dts-probe-binaries]# cat popcnt.c 
#include <stdio.h>
int
main (int argc, char *argv[] __attribute__((unused)))
{
  printf ("%p\n", main);
  return __builtin_popcount (argc);
}
[root@ibm-p8-04-lp5 dts-probe-binaries]#

[root@ibm-p8-04-lp5 dts-probe-binaries]# gcc -g3 -Wall -O2 -o popcnt popcnt.c; nm --debug-syms popcnt | grep gmon
                 w __gmon_start__
[root@ibm-p8-04-lp5 dts-probe-binaries]# 


Command above were ran on ppc64 box, compare the output with DTS gcc/binutils on the same box:

[root@ibm-p8-04-lp5 dts-probe-binaries]# scl enable devtoolset-6 'gcc -g3 -Wall -O2 -o popcnt popcnt.c; nm --debug-syms popcnt | grep gmon'
[root@ibm-p8-04-lp5 dts-probe-binaries]# 


__gmon_start__ (among others) is missing. However the same commands on x86_64, aarch64 and even ppc64le give different results:

[root@phenom-01 dts-probe-binaries]# arch
x86_64
[root@phenom-01 dts-probe-binaries]# gcc -g3 -Wall -O2 -o popcnt popcnt.c; nm --debug-syms popcnt | grep gmon
                 w __gmon_start__
[root@phenom-01 dts-probe-binaries]# scl enable devtoolset-6 'gcc -g3 -Wall -O2 -o popcnt popcnt.c; nm --debug-syms popcnt | grep gmon'
                 w __gmon_start__
[root@phenom-01 dts-probe-binaries]# 


[root@ibm-p8-rhevm-16 dts-probe-binaries]# arch
ppc64le
[root@ibm-p8-rhevm-16 dts-probe-binaries]# gcc -g3 -Wall -O2 -o popcnt popcnt.c; nm --debug-syms popcnt | grep gmon
                 w __gmon_start__
[root@ibm-p8-rhevm-16 dts-probe-binaries]# scl enable devtoolset-6 'gcc -g3 -Wall -O2 -o popcnt popcnt.c; nm --debug-syms popcnt | grep gmon'
00000000100003e0 t 00000025.plt_call.__gmon_start__
                 w __gmon_start__
[root@ibm-p8-rhevm-16 dts-probe-binaries]# 



Version-Release number of selected component (if applicable):

binutils-2.25.1-20.base.el7.ppc64
devtoolset-6-binutils-2.27-3.el7.ppc64
devtoolset-6-gcc-6.1.1-4.1.el7.ppc64
gcc-4.8.5-9.el7.ppc64

Same builds on all boxes.


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Nick Clifton 2016-08-09 14:36:01 UTC
Hi Miloš,

  Hmm, at first I was tempted to say that this is just not-a-bug, but upon reading more closely it does seem suspicious.  Could you run a few checks for me please ?

  1.  Does the ppc64 DTS 6 popcnt binary actually work ?

  2.  What is the output of nm --debug-syms popcnt ?  (ie without the grep)

  3.  The weak reference to __gmon_start__ comes from crti.o (at least for the x86_64), so would it be possible to check that the crti.o used in the ppc64 DTS6 environment actually contains a reference to __gmon_start__ ?

  4. What is the output, if any, of running (on your ppc64 machine):

scl enable devtoolset-6 'gcc -g3 -Wall -O2 -o popcnt -Wl,--trace-symbol,__gmon_start__ popcnt.c; nm --debug-syms popcnt | grep gmon'

Cheers
  Nick

Comment 2 Nick Clifton 2016-08-09 14:37:19 UTC
Sorry for test 4 I meant:

  scl enable devtoolset-6 'gcc -g3 -Wall -O2 -o popcnt -Wl,--trace-symbol,__gmon_start__ popcnt.c'

 Ie without running nm or grep.

Comment 3 Nick Clifton 2016-08-10 11:06:05 UTC
Right - I am going to close this as WONTFIX.

The summary is that this behaviour itself is not a bug, but it does mask an underlying, unusual "feature" of the PPC64 ABI.  This feature has been present forever however, and is not going to be changed any time soon.

Here is what is actually going on: On most ELF based systems where shared libraries are supported a dynamic executable can contain undefined weak symbols.  These are weak symbol references that were present in one or more of the objects that make up the executable, and which have not been found in any of the shared libraries present when the executable was linked.  The theory is that at run-time, if a loaded shared library does then define the symbol (because the loaded shared library is not the same one as was used when linking happened), then the weak symbol reference will be resolved.

The case of the __gmon_start__ symbol is slightly different.  It is present in the crt1.o startup code as a weak reference so that if the executable provides a definition of it (usually pointing to __monstartup) then it will be called.  This is how gmon profiling gets started.  If the symbol is not defined somewhere in then the symbol is left NULL and the code in crt1.o never calls it.  It is not expected that a shared library will provide a definition of __gmon_start__, but the ELF specification does allow for it.

This is where PPC64 differs from other Linux targets.  It does not allocate PLT entries for undefined weak symbols in the executable, so they can never be resolved, even if a loaded shared library does define them.  This is standard behaviour for the PPC64 linker and has been in there forever.  (Well since version 2.11 of the binutils at least).  I presume that it is part of the PPC64
ABI, although I do not have any documentation to confirm this.

The result of this behaviour is that undefined weak symbols in a PPC64 dynamic executable will never be resolved.  The only change with the 2.27 binutils release then is that these unused symbols are no longer left in the executable, but instead they are stripped out.  Ie the change with 2.27 is a small optimization to remove unused symbols from an executable, and this change is not a bug at all.

I am closing with WONTFIX rather than NOTABUG because I have not actually seen the PPC64 ABI to confirm this behaviour.  (But I have had it confirmed by Alan Modra).  It is theoretically possible that this is a long standing bug in the PPC64 linker however, and now that it has been exposed it might be fixed.

Cheers
  Nick

Comment 4 Nick Clifton 2016-08-10 11:09:54 UTC
Oops typo.  This sentence:

  "If the symbol is not defined somewhere in then the symbol is left NULL and the code in crt1.o never calls it."

should have been:

  "If the symbol is not defined somewhere in the executable then the reference in crt1.o is left as NULL and so it is never called."

Comment 5 Nick Clifton 2016-08-11 09:56:58 UTC
Ha - I spoke too soon!

It seems that after asking Alan Modra about this problem he has decided that it was a bug after all and that it needs fixing:

  https://sourceware.org/ml/binutils/2016-08/msg00071.html

I am still of the opinion however that applying this patch to DTS 6 would not be a good idea, on the grounds that it changes very sensitive code in the linker, and if the patch does introduce a new bug then that would be bad.  Plus, the behaviour that the patch is fixing has never triggered a bug report before, despite its long existence.

Comment 6 Jeff Law 2016-08-11 16:32:54 UTC
Just to be clear though, this behavior change in the linker just affects what symbols show up in executables/DSOs?   So unless an executable/DSO was introspecting on its own symbol table, it won't affect the behavior of the executable/DSO, right?

Comment 7 Nick Clifton 2016-08-12 10:43:51 UTC
(In reply to Jeff Law from comment #6)
> Just to be clear though, this behavior change in the linker just affects
> what symbols show up in executables/DSOs?

Right - and the only symbols affected are undefined weak symbols.

> So unless an executable/DSO was
> introspecting on its own symbol table, it won't affect the behavior of the
> executable/DSO, right?

Right.  Plus of course if an external tool inspects the executable/DSO's symbol table then it too will see a change - hence the problem that triggered this BZ.

Comment 8 Jeff Law 2016-08-16 21:36:47 UTC
THanks.  I think this is fine as a WONTFIX, or if QE wants, we can defer it until DTS-7 where it will be fixed (and have had time to soak test upstream).


Note You need to log in before you can comment on or make changes to this bug.