Hi, >> If it is related to my validation patches, I suggest you check you use >> GCC which generates correct frame info in the first place (4.5.0 or >> newer) for as much code as you can, then check to make sure addresses >> are validated correctly on your platform. > > We are still using gcc 4.3 and while it would be relatively > straight-forward to update to 4.4, I don't think there's support for > version 4.5 in buildroot yet. Would updating to gcc 4.4 be worthwhile?
AFAIK all GCC versions prior to 4.5.0 generate incorrect unwind tables, at least on x86-64, so no, 4.4 wouldn't help. The problem is that there is no unwind info for the function epilogues, so if you happen to unwind through a frame in the middle of epilogue, wrong values will be restored. I am not positive ARM is affected, but I understood the bug was general. You can trivially see if your code is affected by comparing "objdump -d" disassembly and unwind info, and see if epilogue code paths in your functions have unwind table entries. If there are no unwind instructions for 'pop' type instructions, then your GCC has the bug. If you are hitting a legitimate code address which falls off normal dwarf unwind routines, then it's unlikely to be related. That more likely means you simply have code which doesn't have unwind info at all, or libunwind isn't finding it for some reason. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
