How to track the call stack of gcc
Basile Starynkevitch
basile@starynkevitch.net
Fri Mar 14 12:42:41 GMT 2025
On Fri, 2025-03-14 at 11:38 +0000, Jonathan Wakely via Gcc-help wrote:
> On Fri, 14 Mar 2025 at 10:44, Gwen Fu via Gcc-help <gcc-help@gcc.gnu.org>
> wrote:
> >
> > Dear gcc community:
> > I am trying to clear out bug'119222'.It is a bug related to C++
> > floating-point operations where the divisor is o without warning (such as
> > "return 1/static_cast<double>0;").
> >
> > Now I am managing to figure out which part of the project is about Warning
> > andFloating point operation.
> > I ran gdb and valgrind.It is feasible but a little complicated. Is there
> > any other method? If not, I will try to get used to it!
>
> https://gcc.gnu.org/wiki/DebuggingGCC has some tips on effective
> debugging of the GCC executables.
The GCC compiler is containing Ian Lance Taylor's libbacktrace.
a possibility is to use that library to print your call stack from inside your
C++ code inside GCC.
If you want an example, I am using libbacktrace and printing the call stack in
https://github.com/RefPerSys/RefPerSys (which is also GPL licensed but not
related to GCC, it is an inference engine project).
Inside GCC libbacktrace is used in gcc/diagnostic-format-sarif.cc and
gcc/simple-diagnostic-path.cc and the internal_error function
BTW, GCC is accepting plugins, and you might consider prototyping your
improvement first as a GCC plugin (for a recent released version of GCC, but not
necessarily its GCC trunk).
Given that GCC use gengtype for garbage collection I don't think it is useful to
use valgrind. See https://arxiv.org/abs/1109.0779
AFAIK GCC is (on purpose) leaking some small amount of memory. In other words,
valgrind will report some memory leaks. It does not matter in practice.
You could also look into the unmaintained https://github.com/bstarynk/bismon
which was about static analysis of GCC compiled code (using GCC plugins).
My recommendation is to focus on bug'119222' but not pay too much attention on
using valgrind. Of course GDB stays very useful. Adding your debug printing is
in practice very useful too.
In some cases, using a better than CPP preprocessor on your code (e.g. GPP from
https://logological.org/gpp) could be useful at least to debug (generate prints)
your GCC plugin.
Regards.
--
Basile STARYNKEVITCH <basile@starynkevitch.net>
8 rue de la Faïencerie
92340 Bourg-la-Reine, France
http://starynkevitch.net/Basile & https://github.com/bstarynk
More information about the Gcc-help
mailing list