If you link with -rdynamic you can show a backtrace with something
like the attached code.
On Wed, Aug 29, 2012 at 9:22 AM, Ian Lance Taylor wrote:
> I've spent the last couple of days working on a stack backtrace library.
>
> It uses the GCC unwind interface to collect a stack trace, and parses
On Thu, 13 Sep 2012, Diego Novillo wrote:
>
> Thanks for the patch!
>
>
> On 2012-09-13 08:46 , Richard Guenther wrote:
>
> > Index: gcc/testsuite/g++.dg/ext/builtin-location.C
> > ===
> > *** /dev/null 1970-01-01 00:00:00.0
Thanks for the patch!
On 2012-09-13 08:46 , Richard Guenther wrote:
Index: gcc/testsuite/g++.dg/ext/builtin-location.C
===
*** /dev/null 1970-01-01 00:00:00.0 +
--- gcc/testsuite/g++.dg/ext/builtin-location.C 2012-0
On Thu, 13 Sep 2012, Richard Guenther wrote:
> On Wed, 12 Sep 2012, Gabriel Dos Reis wrote:
>
> > On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo wrote:
> >
> > > Alternately, we could use Richi's approach I suppose (what happened to
> > > that
> > > patch, btw)?
> >
> > I was under the impre
On Wed, 12 Sep 2012, Gabriel Dos Reis wrote:
> On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo wrote:
>
> > Alternately, we could use Richi's approach I suppose (what happened to that
> > patch, btw)?
>
> I was under the impression that the patch was good to go in; Richard?
Yes. I've made the
On Wed, Sep 12, 2012 at 9:50 AM, Diego Novillo wrote:
> On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote:
>
>> Diego already loves it!
>
>
> Indeed I do!
>
> I'm making changes in VEC that will benefit from this. I am currently
> keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__
On Wed, Sep 12, 2012 at 2:31 PM, wrote:
> Only of the checking parts, right? Not of the mem stat ones.
Correct. I'm thinking mostly of operator[].
> I have to get back to it. Maybe tomorrow ...
Great, thanks. I will keep the macros around for now. They can be
removed later.
Diego.
Diego Novillo wrote:
>On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote:
>
>> Diego already loves it!
>
>Indeed I do!
>
>I'm making changes in VEC that will benefit from this. I am currently
>keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to
>the methods that want it. But
On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo wrote:
> Alternately, we could use Richi's approach I suppose (what happened to that
> patch, btw)?
I was under the impression that the patch was good to go in; Richard?
-- Gaby
On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote:
Diego already loves it!
Indeed I do!
I'm making changes in VEC that will benefit from this. I am currently
keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to
the methods that want it. But it would be nice if we could ge
On 8/29/12, Gabriel Dos Reis wrote:
> On Aug 29, 2012 Ian Lance Taylor wrote:
> > Does this seem like something we could usefully add to GCC?
>
> Emphatically, yes!.
Seconded!
> Does anybody see any big problems with it?
>
> Can it would be a great addition to libstdc++ as a GNU extension,
> st
On Thu, Aug 30, 2012 at 1:04 AM, Florian Weimer wrote:
> On 08/29/2012 09:22 AM, Ian Lance Taylor wrote:
>
>> It uses the GCC unwind interface to collect a stack trace, and parses
>> DWARF debug info to get file/line/function information. (Of course it's
>> silly to write yet another DWARF reader
On 08/29/2012 08:40 PM, Toon Moene wrote:
On 08/29/2012 06:21 PM, Ian Lance Taylor wrote:
The DWARF reader calls malloc and is therefore not async-signal safe.
It also is a problem if the crash in the program is due to overwriting
the malloc heap administration (which easily occurs in Fortran
On 08/29/2012 09:22 AM, Ian Lance Taylor wrote:
It uses the GCC unwind interface to collect a stack trace, and parses
DWARF debug info to get file/line/function information. (Of course it's
silly to write yet another DWARF reader, but I didn't find an existing
reader that seemed wholly suitable
On Wed, Aug 29, 2012 at 11:45 AM, Paweł Sikora wrote:
> On Wednesday 29 of August 2012 11:37:07 Ian Lance Taylor wrote:
>> On Wed, Aug 29, 2012 at 1:07 AM, Paweł Sikora wrote:
>> > On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
>> >> I've spent the last couple of days working on
On Wed, Aug 29, 2012 at 9:31 AM, H.J. Lu wrote:
> On Wed, Aug 29, 2012 at 9:21 AM, Ian Lance Taylor wrote:
>>
>> I believe the unwinder proper is async signal safe--it just uses
>> _Unwind_Backtrace.
>>
>> The DWARF reader calls malloc and is therefore not async-signal safe.
>> It would be diffic
On Wednesday 29 of August 2012 11:37:07 Ian Lance Taylor wrote:
> On Wed, Aug 29, 2012 at 1:07 AM, Paweł Sikora wrote:
> > On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
> >> I've spent the last couple of days working on a stack backtrace library.
> >>
> >> It uses the GCC unwind
On 08/29/2012 06:21 PM, Ian Lance Taylor wrote:
The DWARF reader calls malloc and is therefore not async-signal safe.
It also is a problem if the crash in the program is due to overwriting
the malloc heap administration (which easily occurs in Fortran if you
overwrite bounds of allocatable a
On Wed, Aug 29, 2012 at 1:07 AM, Paweł Sikora wrote:
> On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
>> I've spent the last couple of days working on a stack backtrace library.
>>
>> It uses the GCC unwind interface to collect a stack trace, and parses
>> DWARF debug info to get
On 08/29/2012 12:43 AM, Janne Blomqvist wrote:
On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor wrote:
I've spent the last couple of days working on a stack backtrace library.
It uses the GCC unwind interface to collect a stack trace, and parses
DWARF debug info to get file/line/function inf
On Wed, Aug 29, 2012 at 9:21 AM, Ian Lance Taylor wrote:
> On Wed, Aug 29, 2012 at 12:43 AM, Janne Blomqvist
> wrote:
>> On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor wrote:
>>> I've spent the last couple of days working on a stack backtrace library.
>>>
>>> It uses the GCC unwind interface
On Wed, Aug 29, 2012 at 12:43 AM, Janne Blomqvist
wrote:
> On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor wrote:
>> I've spent the last couple of days working on a stack backtrace library.
>>
>> It uses the GCC unwind interface to collect a stack trace, and parses
>> DWARF debug info to get f
On Wed, Aug 29, 2012 at 6:27 AM, Michael Matz wrote:
>
> On Wed, 29 Aug 2012, Ian Lance Taylor wrote:
>
>> Does this seem like something we could usefully add to GCC? Does
>> anybody see any big problems with it?
>
> Does it work without unwind tables? I suspect it doesn't as it's using
> libgcc
Basile Starynkevitch writes:
> [...] If Ian's DWARF reader is simple enough (since suited for a
> single purpose), it might be helpful to avoid yet another external
> library dependency for GCC. [...]
OTOH, DWARF is not a stationary target, so one should consider the
benefits of offloading fors
Hi,
On Wed, 29 Aug 2012, Ian Lance Taylor wrote:
> Does this seem like something we could usefully add to GCC? Does
> anybody see any big problems with it?
Does it work without unwind tables? I suspect it doesn't as it's using
libgccs unwinder, so that would be a problem if we were to use it
On Wed, Aug 29, 2012 at 10:07:30AM +0200, Paweł Sikora wrote:
> On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
> > I've spent the last couple of days working on a stack backtrace library.
> >
> > It uses the GCC unwind interface to collect a stack trace, and parses
> > DWARF debug
On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
> I've spent the last couple of days working on a stack backtrace library.
>
> It uses the GCC unwind interface to collect a stack trace, and parses
> DWARF debug info to get file/line/function information. (Of course it's
> silly to
On Wed, Aug 29, 2012 at 02:47:18AM -0500, Gabriel Dos Reis wrote:
> On Wed, Aug 29, 2012 at 2:22 AM, Ian Lance Taylor wrote:
>
> > Does this seem like something we could usefully add to GCC?
>
> Emphatically, yes!.
I also think it would be very useful.
BTW, MELT has also such a feature (which
On Wed, Aug 29, 2012 at 2:22 AM, Ian Lance Taylor wrote:
> Does this seem like something we could usefully add to GCC?
Emphatically, yes!.
> Does anybody see any big problems with it?
Can it would be a great addition to libstdc++ as a GNU extension, stached
in the namespace.
I do also do li
On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor wrote:
> I've spent the last couple of days working on a stack backtrace library.
>
> It uses the GCC unwind interface to collect a stack trace, and parses
> DWARF debug info to get file/line/function information.
[snip]
> I expect to use this cod
30 matches
Mail list logo
