* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
@ 2007-01-18 18:00 ` fxcoudert at gcc dot gnu dot org
2007-02-07 9:08 ` fxcoudert at gcc dot gnu dot org
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-01-18 18:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-18 17:59 -------
(In reply to comment #0)
> "It was mentionned on IRC tonight that Daniel Berlin has a library that
> extracts line and file information from DWARF2 info. It's internal to Google, but he
> said he'll see if he can get it released. We'll have to get back to him in some
> time..."
I since spoke to him again, and we'd better go ahead with our current plan.
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2007-01-18 17:59:49
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
2007-01-18 18:00 ` [Bug libfortran/30498] " fxcoudert at gcc dot gnu dot org
@ 2007-02-07 9:08 ` fxcoudert at gcc dot gnu dot org
2007-02-07 9:47 ` burnus at gcc dot gnu dot org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-02-07 9:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-07 09:08 -------
Created an attachment (id=13019)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13019&action=view)
Patch implementing the -fbacktrace option
Here's an updated version of the patch I submitted some time ago. I don't have
enough time to submit it, but if someone wants to take it and do whatever you
want to do with it, go ahead!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
2007-01-18 18:00 ` [Bug libfortran/30498] " fxcoudert at gcc dot gnu dot org
2007-02-07 9:08 ` fxcoudert at gcc dot gnu dot org
@ 2007-02-07 9:47 ` burnus at gcc dot gnu dot org
2007-02-08 20:30 ` patchapp at dberlin dot org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-07 9:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from burnus at gcc dot gnu dot org 2007-02-07 09:47 -------
> Patch implementing the -fbacktrace option
I think one should add also some userhandler
signal(SIGSEGV, my_segv_handler);
which calls show_backtrace and exits/coredumps then.
That way we calso get a backtrace for signalling arithmetic errors or for wrong
pointer accesses etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (2 preceding siblings ...)
2007-02-07 9:47 ` burnus at gcc dot gnu dot org
@ 2007-02-08 20:30 ` patchapp at dberlin dot org
2007-02-09 7:44 ` P dot Schaffnit at access dot rwth-aachen dot de
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: patchapp at dberlin dot org @ 2007-02-08 20:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from patchapp at dberlin dot org 2007-02-08 20:30 -------
Subject: Bug number PR30498
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00747.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (3 preceding siblings ...)
2007-02-08 20:30 ` patchapp at dberlin dot org
@ 2007-02-09 7:44 ` P dot Schaffnit at access dot rwth-aachen dot de
2007-02-09 8:16 ` fxcoudert at gcc dot gnu dot org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: P dot Schaffnit at access dot rwth-aachen dot de @ 2007-02-09 7:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de 2007-02-09 07:44 -------
Hi!
This is great!
I cannot judge how much work this would be, but would it be possible to extend
this patch a little further so that these backtraces can be requested by the
user? (i.e. like the service routines 'ERRTRA' from Lahey, 'TRACEBACKQQ' from
Digital|Compaq|HP|Intel or 'Trace_Back_Stack_and_Print' from SGI). This way it
can also be used for user error handling...
Thanks!
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (4 preceding siblings ...)
2007-02-09 7:44 ` P dot Schaffnit at access dot rwth-aachen dot de
@ 2007-02-09 8:16 ` fxcoudert at gcc dot gnu dot org
2007-02-09 8:25 ` P dot Schaffnit at access dot rwth-aachen dot de
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-02-09 8:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-09 08:15 -------
(In reply to comment #5)
> I cannot judge how much work this would be, but would it be possible to extend
> this patch a little further so that these backtraces can be requested by the
> user? (i.e. like the service routines 'ERRTRA' from Lahey, 'TRACEBACKQQ' from
> Digital|Compaq|HP|Intel or 'Trace_Back_Stack_and_Print' from SGI). This way it
> can also be used for user error handling...
It's very easy to implement, but should we add yet another GNU-specific
intrinsic?
Or maybe we could add have a GNU_EXTENSIONS module that would allow us to
access our GNU-specific intrinsics.
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2007-02-07 09:08:46 |2007-02-09 08:15:58
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (5 preceding siblings ...)
2007-02-09 8:16 ` fxcoudert at gcc dot gnu dot org
@ 2007-02-09 8:25 ` P dot Schaffnit at access dot rwth-aachen dot de
2007-02-09 9:56 ` burnus at gcc dot gnu dot org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: P dot Schaffnit at access dot rwth-aachen dot de @ 2007-02-09 8:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from P dot Schaffnit at access dot rwth-aachen dot de 2007-02-09 08:25 -------
The Digital|Compaq|HP|Intel implementation goes for a module 'DFLIB', though I
have to admit I get lost with the pros and cons.
Regarding whether this should be implemented at all, I would be very
self-centered and point that several other compilers support this extension, so
there had to be enough people requesting it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (6 preceding siblings ...)
2007-02-09 8:25 ` P dot Schaffnit at access dot rwth-aachen dot de
@ 2007-02-09 9:56 ` burnus at gcc dot gnu dot org
2007-02-09 10:05 ` P dot Schaffnit at access dot rwth-aachen dot de
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-09 9:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from burnus at gcc dot gnu dot org 2007-02-09 09:55 -------
Hi,
> I cannot judge how much work this would be, but would it be possible to extend
> this patch a little further so that these backtraces can be requested by the
> user?
Well, this is possible if one combines this patch with the ISO C Bindings of
our fortran-experiments branch. One could then simply use:
integer, parameter :: SIGBUS = 7
integer :: res
interface
function kill(pid, signal) bind(c, name='kill')
use :: ISO_C_BINDING
integer(C_INT),value :: pid, signal
integer(C_INT),bind(c) :: kill
end function kill
end interface
res = kill(0,SIGBUS)
To get a backtrace. Alternatively, with the current patch and the main branch,
one only needs to generate somehow SIGSEGV, SIGFPE, SIGILL or SIGBUS. For
instance as follows:
-ffpe-trap=zero -fbacktrace with
r = 0.0
r = 1.0/r
which gives a nice backtrace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (7 preceding siblings ...)
2007-02-09 9:56 ` burnus at gcc dot gnu dot org
@ 2007-02-09 10:05 ` P dot Schaffnit at access dot rwth-aachen dot de
2007-02-09 13:25 ` P dot Schaffnit at access dot rwth-aachen dot de
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: P dot Schaffnit at access dot rwth-aachen dot de @ 2007-02-09 10:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from P dot Schaffnit at access dot rwth-aachen dot de 2007-02-09 10:05 -------
Hi!
I had indeed thought about using soem variation on '0. / 0.', but I find it
somewhat messy...
Somehow generating a kill from C does looks like a viable alternative though (I
would maybe not wait for the ISO C bindings and put that in an additional C
routine).
I nevertheless consider it only a second choice (though I could personally live
with it!).
Thanks a lot!
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (8 preceding siblings ...)
2007-02-09 10:05 ` P dot Schaffnit at access dot rwth-aachen dot de
@ 2007-02-09 13:25 ` P dot Schaffnit at access dot rwth-aachen dot de
2007-02-21 11:59 ` P dot Schaffnit at access dot rwth-aachen dot de
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: P dot Schaffnit at access dot rwth-aachen dot de @ 2007-02-09 13:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from P dot Schaffnit at access dot rwth-aachen dot de 2007-02-09 13:25 -------
In case anyone is interested: as mnetioned in Comment #8, just calling this
tiny C routine causes a traceback
#include <sys/types.h>
#include <signal.h>
void checktraceback_()
{
kill ( (pid_t)0, SIGILL );
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (9 preceding siblings ...)
2007-02-09 13:25 ` P dot Schaffnit at access dot rwth-aachen dot de
@ 2007-02-21 11:59 ` P dot Schaffnit at access dot rwth-aachen dot de
2007-03-10 16:47 ` burnus at gcc dot gnu dot org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: P dot Schaffnit at access dot rwth-aachen dot de @ 2007-02-21 11:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from P dot Schaffnit at access dot rwth-aachen dot de 2007-02-21 11:58 -------
Hi!
I don't seem to be able to apply this patch to '122195' sources: did it get out
of synch, or is it plain clumsiness on my part?
I get:
Hunk #2 FAILED at 3151.
1 out of 2 hunks FAILED -- saving rejects to file gcc/fortran/trans-decl.c.rej
patching file gcc/fortran/options.c
This is probably very clear when one knows what it's all about, but
unfortunately that's not the case for me...
Thanks!
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (10 preceding siblings ...)
2007-02-21 11:59 ` P dot Schaffnit at access dot rwth-aachen dot de
@ 2007-03-10 16:47 ` burnus at gcc dot gnu dot org
2007-03-14 22:12 ` fxcoudert at gcc dot gnu dot org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-03-10 16:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from burnus at gcc dot gnu dot org 2007-03-10 16:47 -------
Latest patch:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00607.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (11 preceding siblings ...)
2007-03-10 16:47 ` burnus at gcc dot gnu dot org
@ 2007-03-14 22:12 ` fxcoudert at gcc dot gnu dot org
2007-03-15 12:57 ` fxcoudert at gcc dot gnu dot org
2007-05-14 9:06 ` P dot Schaffnit at access dot rwth-aachen dot de
14 siblings, 0 replies; 16+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-03-14 22:12 UTC (permalink / raw)
To: gcc-bugs
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-02-09 08:15:58 |2007-03-14 22:11:52
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (12 preceding siblings ...)
2007-03-14 22:12 ` fxcoudert at gcc dot gnu dot org
@ 2007-03-15 12:57 ` fxcoudert at gcc dot gnu dot org
2007-05-14 9:06 ` P dot Schaffnit at access dot rwth-aachen dot de
14 siblings, 0 replies; 16+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-03-15 12:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-03-15 12:57 -------
Commited to 4.3, closing.
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug libfortran/30498] Support traceback (backtrace) on errors
2007-01-18 12:46 [Bug libfortran/30498] New: Support traceback (backtrace) on errors burnus at gcc dot gnu dot org
` (13 preceding siblings ...)
2007-03-15 12:57 ` fxcoudert at gcc dot gnu dot org
@ 2007-05-14 9:06 ` P dot Schaffnit at access dot rwth-aachen dot de
14 siblings, 0 replies; 16+ messages in thread
From: P dot Schaffnit at access dot rwth-aachen dot de @ 2007-05-14 9:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from P dot Schaffnit at access dot rwth-aachen dot de 2007-05-14 10:06 -------
Hi!
Sorry about the noise, I'm wondering: the trick of using a tiny C routine:
kill ( (pid_t)0, SIGILL );
is there any obvious reason for that?
Thanks!
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
^ permalink raw reply [flat|nested] 16+ messages in thread