* No unwind info for __do_global_ctors_aux / _init? @ 2010-03-09 11:28 Lassi Tuura 2010-03-10 15:52 ` Ian Lance Taylor 0 siblings, 1 reply; 4+ messages in thread From: Lassi Tuura @ 2010-03-09 11:28 UTC (permalink / raw) To: gcc-help Hi, I maintain a profiling utility which uses libunwind to capture stack traces on x86-64. One of the several problems we ran into is that stack tracing stops at global constructors for dynamically loaded shared libraries. This seems to be because there is no unwind information for _init / __do_global_ctors_aux. Is there any way to coax GCC to generate .eh_frame information for these functions? I tried recompiling one library with and without -fasynchronous-unwind-tables on a RHEL5-derived system with GCC 4.3.4 + binutils 2.19.1, but didn't get the extra unwind info. In fact -fasynchronous-unwind-tables didn't make any difference that I could tell. Regards, Lassi ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: No unwind info for __do_global_ctors_aux / _init? 2010-03-09 11:28 No unwind info for __do_global_ctors_aux / _init? Lassi Tuura @ 2010-03-10 15:52 ` Ian Lance Taylor 2010-03-10 16:19 ` Lassi Tuura 0 siblings, 1 reply; 4+ messages in thread From: Ian Lance Taylor @ 2010-03-10 15:52 UTC (permalink / raw) To: Lassi Tuura; +Cc: gcc-help Lassi Tuura <lat@cern.ch> writes: > I maintain a profiling utility which uses libunwind to capture stack > traces on x86-64. One of the several problems we ran into is that > stack tracing stops at global constructors for dynamically loaded > shared libraries. This seems to be because there is no unwind > information for _init / __do_global_ctors_aux. > > Is there any way to coax GCC to generate .eh_frame information for > these functions? You could try modifying the gcc Makefile to add -funwind-tables or -fasynchronous-unwind-tables to CRTSTUFF_CFLAGS. > I tried recompiling one library with and without > -fasynchronous-unwind-tables on a RHEL5-derived system with GCC > 4.3.4 + binutils 2.19.1, but didn't get the extra unwind info. In > fact -fasynchronous-unwind-tables didn't make any difference that I > could tell. -fasynchronous-unwind-tables should make a difference, and it is required if you want to be able to reliably unwind the stack from a signal handler. By the way, if you aren't using mainline gcc I think you'll find that the unwind information is incorrect in function epilogues, which means that unwinding the stack from a signal handler will break if the signal comes in as a function is returning. I think this may be fixed in mainline. Ian ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: No unwind info for __do_global_ctors_aux / _init? 2010-03-10 15:52 ` Ian Lance Taylor @ 2010-03-10 16:19 ` Lassi Tuura 2010-03-10 16:34 ` Ian Lance Taylor 0 siblings, 1 reply; 4+ messages in thread From: Lassi Tuura @ 2010-03-10 16:19 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc-help Hi, Thanks for your response. >> Is there any way to coax GCC to generate .eh_frame information for >> these functions? > > You could try modifying the gcc Makefile to add -funwind-tables or > -fasynchronous-unwind-tables to CRTSTUFF_CFLAGS. Thanks, I'll give that a go. >> I tried recompiling one library with and without >> -fasynchronous-unwind-tables on a RHEL5-derived system with GCC >> 4.3.4 + binutils 2.19.1, but didn't get the extra unwind info. In >> fact -fasynchronous-unwind-tables didn't make any difference that I >> could tell. > > -fasynchronous-unwind-tables should make a difference, and it is > required if you want to be able to reliably unwind the stack from a > signal handler. I'll try to debug what goes wrong here. FWIW, I don't want to unwind in the sense of throwing an exception, just trace the stack as well as reasonably possible. As it happens I haven't yet come across profile corruption because of this, I think, only other issues (e.g. epilogue). At any rate, it's a trade-off for us. We can live with a small fraction of corrupt stack traces. At the moment "small" is 10% which obviously isn't good enough. Some of this is issues in libunwind, not compiler. > By the way, if you aren't using mainline gcc I think you'll find that > the unwind information is incorrect in function epilogues, which means > that unwinding the stack from a signal handler will break if the > signal comes in as a function is returning. I think this may be fixed > in mainline. Yes, I discovered this and was reading through the patches the other day. Up to about to five percent of our stack traces are corrupted because of this. Unfortunately the system libraries (libc, libm) have this issue as well, which makes it rather thorny for us to fix. By "mainline" do you mean this isn't in any release yet? Hm, will have to try to pull those patches separately then. Regards, Lassi ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: No unwind info for __do_global_ctors_aux / _init? 2010-03-10 16:19 ` Lassi Tuura @ 2010-03-10 16:34 ` Ian Lance Taylor 0 siblings, 0 replies; 4+ messages in thread From: Ian Lance Taylor @ 2010-03-10 16:34 UTC (permalink / raw) To: Lassi Tuura; +Cc: gcc-help Lassi Tuura <lat@cern.ch> writes: > By "mainline" do you mean this isn't in any release yet? Hm, will have > to try to pull those patches separately then. Yes, that is what I mean. Ian ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-03-10 16:34 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-09 11:28 No unwind info for __do_global_ctors_aux / _init? Lassi Tuura 2010-03-10 15:52 ` Ian Lance Taylor 2010-03-10 16:19 ` Lassi Tuura 2010-03-10 16:34 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).