This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [fortran, patch] Allow displaying backtraces from user code
- From: Manfred Schwarb <manfred99 at gmx dot ch>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: FX <fxcoudert at gmail dot com>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Thu, 21 Jun 2012 15:26:55 +0200
- Subject: Re: [fortran, patch] Allow displaying backtraces from user code
- References: <61B50068-0CDB-48AF-95D8-1139D6283FF8@gmail.com> <4FE3104D.8020408@net-b.de>
Am 21.06.2012 14:15, schrieb Tobias Burnus:
On 03/03/2012 08:44 AM, FX wrote [1]:
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an enhancement request for a way to display backtraces from user code.
I wanted to come back to that patch for some while. I think it makes sense to offer this feature in some why and as the PR but also a question on #gfortran shows, there is a need to do so.
It is definitely needed, IMHO.
In a modular program the calling path is often needed to interpret
some hiccups, and a debugger is not always suited.
Program runs are not always reproducible, and with this you can
add debugging statements into operational code.
I ended up writing a wrapper around the c-functions backtrace() and backtrace_symbols_fd(),
but then you have to interpret it externally with addr2line.
There are two possibilities:
a) Making _gfortran_show_backtrace accessible from the outside (via manual C binding from Fortran)
b) Adding a new intrinsic
I would vote for b), as it gets documented then.
It is enough useful for a wide range of programmers to deserve
an intrinsic of its own, IMHO.
And always directly available, no need of module convolutions.
Name: simply show_backtrace ?
This would be a self-explaining name, the odd "QQ" in
tracebackqq is just this, odd.
And why call it traceback when it is actually a backtrace ;-)
Cheers,
Manfred