This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
libgcc vs glibc2 dwarf2 unwinder
- From: Andi Kleen <andi at firstfloor dot org>
- To: libc-alpha at sourceware dot org, rth at redhat dot com, ppluzhnikov at google dot com
- Cc: hjl dot tools at gmail dot com
- Date: Sun, 8 Aug 2010 18:01:27 +0200
- Subject: libgcc vs glibc2 dwarf2 unwinder
[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,
-Andi
--
ak@linux.intel.com -- Speaking for myself only.