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!
> 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.
>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.
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?
Created attachment 54984 [details] 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.
Created attachment 54985 [details] 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.
(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.
(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.
(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.
Sure, no worries.