Re: libgcc vs glibc2 dwarf2 unwinder

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Aug 8, 2010 at 9:01 AM, Andi Kleen <andi@firstfloor.org> wrote:
> [Apologies if you see this twice -- i put the wrong address in first try]
>
> After a recent discussion on this topic on the gcc mailing list
> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00380.html
>
> I investigated how to make the dwarf2 unwinder signal safe, in particular
> stop it from using malloc and taking locks in the dynamic linker.
> This would make it reliable to do backtraces in signal handlers
> on a frame pointer less build.
>
> It's actually not too complicated: malloc can be replaced with mmap
> and the locks can be try locks with a short time out.
>
> But the real problem I ran into during testing is that right now
> the first backtrace() call in a program actually calls the dynamic linker
> to open libgcc1.so and then calls into that. ?That does all kind
> of non signal safe operations of course.
>
> I'm not fully sure why it does that -- the dwarf2 code in glibc looks fairly
> similar to the one in libgcc. I don't think the current scheme
> can be made async safe at least.
>
> As far as I can see there could be two solutions:
>
> - Drop the backtrace wrapper in glibc completely and move it into
> into libgcc.so (it doesn't really do anything anyways)
> - Use the unwinder in glibc again for backtrace() again
> and don't use the one in libgcc.
>
> And then fix the remaining async problems in either one.
>
> I'm not sure which one is better. Comments?
>
> Thanks,

There are 2 other unwinders:

http://www.nongnu.org/libunwind/
http://www.paradyn.org/html/stackwalker1.1-features.html

http://hpctoolkit.org/index.html has its own implementation of stackwalk.

Among all those unwinders, can we find a good solution for our
users?


-- 
H.J.