[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Werner
Subject: Re: [Libunwind-devel] libunwind for linux/arm
Date: Fri, 14 Oct 2011 18:26:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

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

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:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]