This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC stack backtraces


On Wed, Aug 29, 2012 at 12:43 AM, Janne Blomqvist
<blomqvist.janne@gmail.com> wrote:
> On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor <iant@google.com> 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 code not just for GCC proper, but also for libgo
>> (currently libgo uses Go code to parse DWARF, but that is not very
>> satisfactory as that code is only available if it has been imported into
>> the program).  So I put it under a BSD license, although that is open
>> for discussion.  Also in case it finds more uses elsewhere I wrote it in
>> reasonably portable C rather than C++.
>>
>>
>> Does this seem like something we could usefully add to GCC?  Does
>> anybody see any big problems with it?
>
> I haven't looked at the code, but if it is async-signal-safe it could
> be interesting for gfortran. Currently in libgfortran we have a
> backtracing routine, originally written by FX Coudert IIRC, since
> rewritten by yours truly a few times, that uses _Unwind_Backtrace()
> from libgcc and then pipes the output via addr2line, if found. Since
> it's invoked from a signal handler when the program (user program, not
> the compiler!) crashes, it needs to be async-signal-safe. AFAIK the
> current implementation *should* fulfill that requirement. But
> something that would be async-signal-safe and won't need addr2line to
> get symbolic info would be a nice improvement, in particular since
> addr2line doesn't work on OSX, and all that piping stuff doesn't work
> on Windows.

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 difficult to write an efficient DWARF reader that does not
allocate any memory, and I'm not aware of any way to allocate memory
that is defined to be async-signal safe.  That said, as far as I know
mmap is async-signal safe in practice if not in theory, so one
approach would be  to do memory allocation using mmap.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]