On Fri, 2010-09-10 at 12:55 +0200, Lassi Tuura wrote: > > over the last days I have found time to investigate the unwind problem > > on the ARM platform further. It turned out that uClibc was built without > > any debug information. So I have now changed that in the hope that this > > would get the unwinder over __default_sa_restorer() from /lib/libc.so.0. > > Unfortunately this didn't help and the backtrace is still stuck in this > > function. As I explained earlier, getting a backtrace works fine if it > > is invoked from normal code. Only backtraces generated from a signal > > handler have this problem. > > > > I have run this with UNW_DEBUG_LEVEL=1000 and generated a large file > > with debug output. Since this file is definitely too large for this > > list, I've uploaded it here: http://svenfoo.org/misc/arm.unwind > > > > It would be terrific if you guys could have a look at this output and/or > > tell me what else I could try to make this work eventually. > > I extracted the essential interesting parts of your trace below.
Thanks, I have taken the trace off-line now. If someone still needs it, please let me know. > Observations: > > 1) What looks like your stack report is actually one level below where > unwind currently is. Are you reporting IP value after the unw_step() > was taken? Indeed, that was wrong. I've now changed my code to be more in line with the example I found in the tests directory. > 2) It ends at looking for IP=0x40859fe7, but __default_sa_restorer is > at address 0x40859fe8, and previous function is setjmp at 0x40859fdc. > > It looks like you are for some reason landing to one byte before the > actual function. Subtracting one from the caller address is indeed the > default logic when walking up the call tree: you have to back off into > the call instruction itself, the function might end with the call, so > it's valid to look at the byte after the call. > > This means there is either no FDE for __default_sa_restorer at all, or > it wasn't found because it doesn't extend to one byte before the > function, which is needed for this special case. This is the direct > reason for returning -10 (-UNW_ENOINFO). > > Off the top of my head I don't recall how linux on x86/x86_64 sets > this up. I think the return address is also to the beginning of the > sigreturn, so maybe the FDE range extends one byte before? > > Can you double check with readelf there is unwind info for > __default_sa_restorer, and the exact bounds for it? At least in the > output you quoted there is no no FDE for delta 0xbfe8 into libc. > Nearest I found was bee8-0xbeec which is __aeabi_MB_CUR_MAX, and after > that there should be __longjmp, __vfork, clone, __sigsetjmp, setjmp > and _setjmp, in address order, before the __default_sa_restorer. Here's the .debug_frame section for libc.so extracted by readelf: http://svenfoo.org/misc/libc.so.dwarf > As far as I could tell from quick internet search > __default_sa_restorer is an assembler stub, so it needs unwind info to > be entered manually. So it could be that uCLibc simply doesn't have this manual unwind info then? I will search a little, perhaps there's a patch that fixes this. Thanks for your help, Sven _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
