[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] status of ARM support
From: |
Lassi Tuura |
Subject: |
Re: [Libunwind-devel] status of ARM support |
Date: |
Mon, 2 Aug 2010 15:17:20 +0300 |
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