Re: [Libunwind-devel] libunwind for linux/arm

[Ken Werner]

On 10/14/2011 03:33 PM, Harald Servat wrote:
> Hello list,
>
>    I've seen that has been some movement for the linux/arm machines (in
> addition to patches, a thread called "In the linaro environment").

Hello Harald,

>    We've a new ARM machine with ubuntu linux on it. Should I download the
> head of GIT instead libunwind 1.0.1?

Well, I guess I'm a bit biased, but I'd go for the current git. I find 
things are rarely broken and if you are encounter issues - please let us 
know.

> Besides this, should I know something in particular?

libunwind supports three unwind methods on ARM:
A) Use the DWARF information stored in the elf binary
B) Make use of ARM specific unwind tables that get loaded into memory
C) APCS frame parsing

A) requires to build your elf binary with -g, B) requires the 
-funwind-tables gcc switch and C) -mapcs-frame. By default libunwind 
looks at the DWARF info first because it's more accurate and if that 
fails libunwind will use the ARM specific unwind tables. In case 
everything fails it falls back on APCS frame parsing. Since modern 
ARM-Linux systems are using the ARM EABI rather than the APCS this code 
(method C) won't help here. The unwind methods that libunwind is allowed 
to use can be set using  UNW_ARM_UNWIND_METHOD environment variable.

An elf file that comes from a standard Ubuntu deb package (as of today) 
is usually lacking both. The DWARF info isn't there since it's stripped 
from the binary and copied into a special ddeb. The ARM specific unwind 
tables are not generated since the toolchain wasn't configured to do so 
(by default). This means libunwind is not able backtrace through code in 
such binaries/libraries.

> Do I have to compile my apps with -funwind-tables as stated in
> https://wiki.linaro.org/KenWerner/Sandbox/libunwind

Yes, you need -g or/and -funwind-tables. The latter takes less space but 
is not as accurate as DWARF in some corner cases (for example in case an 
async signal interrupted a prologue or epilogue).

You may also add -U_FORTIFY_SOURCE to your CLFAGS until the following 
bug is fixed: http://savannah.nongnu.org/bugs/?28397

Regards
Ken