This is the mail archive of the gcc-patches@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: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86


On 08/04/2010 03:07 PM, Paul Pluzhnikov wrote:
On Wed, Aug 4, 2010 at 2:16 PM, Andi Kleen<andi@firstfloor.org> wrote:

The issue here is not that the unwind info is missing; it's that glibc
backtrace() is not async-signal safe (which, given that it calls malloc
shouldn't be a big surprise :-).

Are you sure? AFAIK it only calls malloc when you register frames, but not during unwinding itself.

Yes, I double-checked this morning.


The self-deadlock sequence observed with glibc-2.11.1 when calling
backtrace() from inside TCMalloc malloc() was the same as in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724:

backtrace() (first time around) calls dlopen("libgcc_s.so.1"), which
(recursively) calls malloc(), which self-deadlocks.

I am sure this particular problem could be resolved, but I am also sure
there are great many other ways in which backtrace() is not async-signal
safe.

Most DWARF unwinding data is not async-signal safe (i.e. it is not generated with -fasynchronous-unwind-tables). So using it to generate a backtrace from an asynchronous signal handler wouldn't be reliable.


David Daney


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