[Bug libc/28153] New: [test] gmon/tst-gmon-gprof* may have a f3 line when built with ld.lld

[Bug libc/28153] New: [test] gmon/tst-gmon-gprof* may have a f3 line when built with ld.lld

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=28153

            Bug ID: 28153
           Summary: [test] gmon/tst-gmon-gprof* may have a f3 line when
                    built with ld.lld
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: i at maskray dot me
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Extracted from
https://sourceware.org/pipermail/libc-alpha/2021-July/129450.html

To build LLD 13.0.0:

# https://github.com/llvm/llvm-project/ origin/release/13.x
cmake -H. -Bout/release -G Ninja -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_PROJECTS='clang;lld'
ninja -C out/release lld

I use
sudo ln -sf out/release/bin/lld /usr/local/bin/ld
to ensure the glibc build system definitely picks ld => lld
(messing around with LDFLAGS=-fuse-ld=lld may work as well)


For gmon/tst-gmon-gprof*, ld.lld linked tst-gmon-gprof has a f3 line, which is
considered a failure by the test. However, having the f3 line appears more
correct to me. I am unclear why ld.bfd tst-gmon-gpro doesn't have f3.

% cat gmon/tst-gmon-gprof.out
--- expected
+++ actual
@@ -1,2 +1,3 @@
 f1 2000
 f2 1000
+f3 1
FAIL

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28153] [test] gmon/tst-gmon-gprof* may have a f3 line when built with ld.lld

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28153

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-07-29

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
On ld.bfd generated gmon/tst-gmon, gprof shows

ndex % time    self  children    called     name
                0.00    0.00    1000/2000        f2 [2]
                0.00    0.00    1000/2000        f3 [7]
[1]      0.0    0.00    0.00    2000         f1 [1]
-----------------------------------------------
                0.00    0.00    1000/1000        f3 [7]
[2]      0.0    0.00    0.00    1000         f2 [2]
                0.00    0.00    1000/2000        f1 [1]
-----------------------------------------------
...
Index by function name

   [1] f1                      [2] f2

Why do you think the output is incorrect?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28153] [test] gmon/tst-gmon-gprof* may have a f3 line when built with ld.lld

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=28153

--- Comment #2 from Fangrui Song <i at maskray dot me> ---
lld linked gmon/tst-gmon has f3.

% cd ~/Dev/glibc/out/lld
% ./testrun.sh gmon/tst-gmon
% gprof gmon/tst-gmon
...

                     Call graph (explanation follows)                           


granularity: each sample hit covers 4 byte(s) no time propagated                

index % time    self  children    called     name
                0.00    0.00    1000/2000        f2 [2]
                0.00    0.00    1000/2000        f3 [3]
[1]      0.0    0.00    0.00    2000         f1 [1]
-----------------------------------------------
                0.00    0.00    1000/1000        f3 [3]
[2]      0.0    0.00    0.00    1000         f2 [2]
                0.00    0.00    1000/2000        f1 [1]
-----------------------------------------------
                0.00    0.00       1/1           main [9]
[3]      0.0    0.00    0.00       1         f3 [3]
                0.00    0.00    1000/1000        f2 [2]
                0.00    0.00    1000/2000        f1 [1]
-----------------------------------------------
...
Index by function name

   [1] f1                      [2] f2                      [3] f3

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28153] [test] gmon/tst-gmon-gprof* may have a f3 line when built with ld.lld

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28153

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
ld.bfd generates:

0000000000401000 T _init
0000000000401090 T main
00000000004010b0 T _start
00000000004010e0 T __gmon_start__
0000000000401130 t deregister_tm_clones
0000000000401160 t register_tm_clones
00000000004011a0 t __do_global_dtors_aux
00000000004011d0 t frame_dummy
0000000000401250 T atexit
0000000000401264 T _fini
0000000000401271 T etext

ld.lld generates:

0000000000201ba0 T _start
0000000000201bd0 T __gmon_start__
0000000000201c20 t deregister_tm_clones
0000000000201c50 t register_tm_clones
0000000000201c90 t __do_global_dtors_aux
0000000000201cc0 t frame_dummy
0000000000201d40 T main
0000000000201d60 t atexit
0000000000201d74 t _init
0000000000201d90 t _fini
0000000000201e10 T etext

glibc assumes that _start is the lowest address for which we need o keep
profiling records.  The newer GCC places main in .text.startup section.
Since _start is in .text section, ld.bfd places main below _start.   Put
_start in .text.startup section makes f3 to show up with ld.bfd.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28153] [test] gmon/tst-gmon-gprof* may have a f3 line when built with ld.lld

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28153

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
A patch is posted at

https://sourceware.org/pipermail/libc-alpha/2021-July/129685.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28153] [test] gmon/tst-gmon-gprof* may have a f3 line when built with ld.lld

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28153

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.35
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
            Version|unspecified                 |2.34

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for glibc 2.35 by

commit 84a7eb1f87c1d01b58ad887a0ab5d87abbc1c772
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Jul 30 19:07:30 2021 -0700

    Use __executable_start as the lowest address for profiling [BZ #28153]

    Glibc assumes that ENTRY_POINT is the lowest address for which we need
    to keep profiling records and BFD linker uses a linker script to place
    the input sections.

    Starting from GCC 4.6, the main function is placed in .text.startup
    section and starting from binutils 2.22, BFD linker with

    commit add44f8d5c5c05e08b11e033127a744d61c26aee
    Author: Alan Modra <amodra@gmail.com>
    Date:   Thu Nov 25 03:03:02 2010 +0000

                * scripttempl/elf.sc: Group .text.exit, text.startup and
.text.hot
                sections.

    places .text.startup section before .text section, which leave the main
    function out of profiling records.

    Starting from binutils 2.15, linker provides __executable_start to mark
    the lowest address of the executable.  Use __executable_start as the
    lowest address to keep the main function in profiling records. This fixes
    [BZ #28153].

    Tested on Linux/x86-64, Linux/x32 and Linux/i686 as well as with
    build-many-glibcs.py.

-- 
You are receiving this mail because:
You are on the CC list for the bug.