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
