[fortran, patch] Allow displaying backtraces from user code

[FX Coudert]

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'm against adding yet another nonstandard intrinsic for this purpose (which is how Intel Fortran does it), but I would like to offer the following solution to the issue, as I think it can be useful in some cases (and the way I suggest should not be a maintainance burden for us):

  -- export _gfortran_show_backtrace() from libgfortran (instead of it being an internal function)
  -- add documentation on how to call this function from user-code using BIND(C)

Patch was bootstrapped and regtested on x86_64-apple-darwin11, also tested with "make info html pdf". OK for trunk?
FX

[Steve Kargl]

On Sat, Mar 03, 2012 at 08:44:56AM +0100, FX wrote:
> 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'm against adding yet another nonstandard intrinsic for this purpose (which is how Intel Fortran does it), but I would like to offer the following solution to the issue, as I think it can be useful in some cases (and the way I suggest should not be a maintainance burden for us):
>
>   -- export _gfortran_show_backtrace() from libgfortran (instead of it being an internal function)
>   -- add documentation on how to call this function from user-code using BIND(C)
>
> Patch was bootstrapped and regtested on x86_64-apple-darwin11, also tested with "make info html pdf". OK for trunk?
> FX
>
>

I think that this approach is a mistake.  The patch
starts us down a slippery slope.  Why not export all
the nonstandard intrinsics?  In additions, the
_gfortran_ prefix was used to separate the libgfortran
namespace from userspace.  Providing a means to
circumvent this separation seems to asking for more
PR.

I would rather see a new intrinsic procedure add to
gfortran.  The standard does not prevent a vendor
from offer additional intrinsic procedures not found
in the standard.

--
Steve

[FX Coudert]

> I think that this approach is a mistake.  The patch
> starts us down a slippery slope.  Why not export all
> the nonstandard intrinsics?  In additions, the
> _gfortran_ prefix was used to separate the libgfortran
> namespace from userspace.  Providing a means to
> circumvent this separation seems to asking for more
> PR.

Well, the mean exists. All _gfortran_* functions can already be called, they're part of libgfortran's public (and versioned) API. I'm just saying adding a simple backtrace function to that list is useful, and documenting it too.

> I would rather see a new intrinsic procedure add to
> gfortran.  The standard does not prevent a vendor
> from offer additional intrinsic procedures not found
> in the standard.

I just think multiplicating vendor intrinsics makes our life harder. I'd like to hear other's opinions on this issue, but I'll implement the new intrinsic if that's the consensus.

Thanks,
FX

[Janus Weil-3]

Hi guys,

(coming back to an old patch proposed by FX some time ago ...)

2012/3/3 FX <fxcoudert@...>:
>> I think that this approach is a mistake.  The patch
>> starts us down a slippery slope.  Why not export all
>> the nonstandard intrinsics?  In additions, the
>> _gfortran_ prefix was used to separate the libgfortran
>> namespace from userspace.  Providing a means to
>> circumvent this separation seems to asking for more
>> PR.
>
> Well, the mean exists. All _gfortran_* functions can already be called, they're part of libgfortran's public (and versioned) API. I'm just saying adding a simple backtrace function to that list is useful, and documenting it too.

Yes, I agree that this is useful, and in that sense the patch is ok
from my side ...


>> I would rather see a new intrinsic procedure add to
>> gfortran.  The standard does not prevent a vendor
>> from offer additional intrinsic procedures not found
>> in the standard.
>
> I just think multiplicating vendor intrinsics makes our life harder. I'd like to hear other's opinions on this issue, but I'll implement the new intrinsic if that's the consensus.

... but I also think that having an intrinsic function for it would be
useful, so that one can just call it without the detour via
ISO_C_BINDING. Note that ifort also has a vendor intrinsic for this,
called TRACEBACKQQ, so we're in good company.

Cheers,
Janus

[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.

There are two possibilities:
a) Making _gfortran_show_backtrace accessible from the outside (via
manual C binding from Fortran)
b) Adding a new intrinsic

The latter is done by other vendors:
- Intel via DEC/Digital has in the module IFCORE the subroutine
TRACEBACKQQ [3]
- Lahey has "call ERRTRA()"
- SGI has "call Trace_Back_Stack_and_Print()"
- IBM has "call xl__trbk()"

FX suggest to do (a).
Steve [4] is for (b)
Janus [3] seems to be fine with (a) but favours (b)
While I have to admit that I am happy either choice.

It seems as if there is a small majority for adding another intrinsic.
The big question is the name and whether it should be available by
default or - as with ifort - via an intrinsic module. One possibility
would be to take the name of and the arguments from Intel's version [3].


Tobias

[1] http://gcc.gnu.org/ml/fortran/2012-03/msg00015.html
[2] http://gcc.gnu.org/ml/fortran/2012-04/msg00131.html
[3]
http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/lin/compiler_f/lref_for/source_files/rftrace.htm
[4] http://gcc.gnu.org/ml/fortran/2012-03/msg00022.html

> I'm against adding yet another nonstandard intrinsic for this purpose (which is how Intel Fortran does it), but I would like to offer the following solution to the issue, as I think it can be useful in some cases (and the way I suggest should not be a maintainance burden for us):
>
>    -- export _gfortran_show_backtrace() from libgfortran (instead of it being an internal function)
>    -- add documentation on how to call this function from user-code using BIND(C)
>
> Patch was bootstrapped and regtested on x86_64-apple-darwin11, also tested with "make info html pdf". OK for trunk?
> FX
>
>

[Manfred Schwarb]

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

[Janus Weil-3]

>> 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.

As noted before, I also prefer b).


> 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 ;-)

Adopting the name from Intel would have the advantage of compatibility
between ifort and gfortran. However, since other vendors have
different names, compatibility between several compilers in this
non-standard function will not be realized. Moreover I agree that the
'QQ' part is odd (I never understood what it is supposed to mean).

Therefore I would also vote for something like "show_backtrace" (or
simply "backtrace"?).

Cheers,
Janus