No unwind info for __do_global_ctors_aux / _init?

No unwind info for __do_global_ctors_aux / _init?

[Lassi Tuura]

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

Re: No unwind info for __do_global_ctors_aux / _init?

[Ian Lance Taylor]

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

Re: No unwind info for __do_global_ctors_aux / _init?

[Lassi Tuura]

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

Re: No unwind info for __do_global_ctors_aux / _init?

[Ian Lance Taylor]

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