--- 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/bugz
--- 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
--
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
--- 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
--- 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 -- sav
--- 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
#include
void checktraceback_()
{
kill ( (pid_t)0, SIGILL );
}
--
--- 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
--- 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
--- 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 ver
--- 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 servi
--- 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 th
--- 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/sh
--- 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
--- 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.
--- 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 c
15 matches
Mail list logo
