[Bug c++/109719] New: Truncated frame-pointer unwinding via Linux perf with g++

[Bug c++/109719] New: Truncated frame-pointer unwinding via Linux perf with g++

[chergert at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

            Bug ID: 109719
           Summary: Truncated frame-pointer unwinding via Linux perf with
                    g++
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chergert at redhat dot com
  Target Milestone: ---

On Fedora 38, frame-pointers are enabled by default. Caveats of course.

However, I noticed that clang++ is generating code that can unwind with
frame-pointers just fine where as g++ is generating code that fails to unwind
past a single frame for some projects.

Where I've noticed this is when profiling GTK/GNOME applications. Harfbuzz,
which is C++ (no-rtti, no-exceptions, no-threadsafe-statics, and no stdlibc++),
regularly results in stacktraces from Linux perf containing 2 frames. One of
them looks corrupted, and the second to a Harfbuzz function.

When I recompile the project with clang++ instead (leaving the rest of the
system still compiled with gcc) I get proper stacktraces from Linux perf
showing how the Harfbuzz API was called (via GLib/GTK/Pango/etc).

Happy to provide more information and/or be remote hands/eyes.

Thanks!

[Bug c++/109719] Truncated frame-pointer unwinding via Linux perf with g++

[chergert at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

--- Comment #1 from Christian Hergert <chergert at redhat dot com> ---
> When I recompile the project with clang++ instead 

I realize this was a bit vague, by "project" I mean Harfbuzz. Simply compiling
Harfbuzz with clang++ made frame-pointer unwinding work by Linux perf.

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-05-03
             Status|UNCONFIRMED                 |WAITING
          Component|c++                         |target
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>On Fedora 38, frame-pointers are enabled by default. Caveats of course.

HUH? omit frame pointer is on by default on x86_64.

What target is this on?

What exact command line is being used to compile the sources? If this on
x86_64, you might still need -mno-omit-leaf-frame-pointer too.

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also on x86_64, frame pointers are not required by the ABI so this is not an
ABI issue. Why instead are you not using the dwarf2 unwind tables that are
generated by default too?

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[chergert at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

--- Comment #4 from Christian Hergert <chergert at redhat dot com> ---
Created attachment 54984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54984&action=edit
First level of stack traces with clang++

This shows a more proper first-level of stack frames within the program as
harfbuzz API will show up in descendants properly.

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[chergert at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

--- Comment #5 from Christian Hergert <chergert at redhat dot com> ---
Created attachment 54985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54985&action=edit
First level of stack traces with g++

This shows stack traces when the only change was compiling harfbuzz with g++
instead of clang++.

Much of the unwinding done by the kernel becomes corrupted and shallow as you
can see by lots of functions which have no business being called before
`_start` or `__GI__clone3` are getting called.

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[chergert at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

--- Comment #6 from Christian Hergert <chergert at redhat dot com> ---
(In reply to Andrew Pinski from comment #2)
> HUH? omit frame pointer is on by default on x86_64.

Yes, Fedora 38 changed the default compiler flags to `-fno-omit-frame-pointer`
so that the system can be profiled more reliably.

> What target is this on?

x86_64

> What exact command line is being used to compile the sources? If this on
> x86_64, you might still need -mno-omit-leaf-frame-pointer too.

No doubt, I have `-mno-omit-leaf-frame-pointer` too.

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[chergert at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

--- Comment #7 from Christian Hergert <chergert at redhat dot com> ---
(In reply to Andrew Pinski from comment #3)
> Also on x86_64, frame pointers are not required by the ABI so this is not an
> ABI issue. Why instead are you not using the dwarf2 unwind tables that are
> generated by default too?

Because the stack unwinding comes from the Linux kernel, which the default
unwinder can only support frame-pointers. The DWARF unwinder was removed long
ago.

Additionally, it can't use `.eh_frame_hdr` either.

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Christian Hergert from comment #6)
> (In reply to Andrew Pinski from comment #2)
> > HUH? omit frame pointer is on by default on x86_64.
> 
> Yes, Fedora 38 changed the default compiler flags to
> `-fno-omit-frame-pointer` so that the system can be profiled more reliably.

So you should report this to Fedora's team.

> 
> > What target is this on?
> 
> x86_64
> 
> > What exact command line is being used to compile the sources? If this on
> > x86_64, you might still need -mno-omit-leaf-frame-pointer too.
> 
> No doubt, I have `-mno-omit-leaf-frame-pointer` too.

I am suspecting the issue is inside the linux kernel ...

Anyways we need much more information here.
A sample simple program which shows that GCC is doing the wrong thing.
Maybe it is the linux frame pointer walker going wrong.

[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++

[chergert at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719

Christian Hergert <chergert at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #9 from Christian Hergert <chergert at redhat dot com> ---
Sure, no worries.