Stack backtrace for ARM/Thumb

[Stern, Eli]

I am using uClibc (as opposed to glibc), so the backtrace() functions do not exist.

I am trying to write a backtrace function, but cannot determine the stack frame for Thumb code, since it seems inconsistent.

I have done several experiments:
1. Compiled using "-mtpcs-frame -mtpcs-leaf-frame". This creates a consistent stack frame, but is very expensive. It adds approximately 15 Thumb instructions per function.
2. Compiled using "-fno-omit-frame-pointer". There were 2 problems here.
2.1 When returning from main(), I did not reach a NULL fp.
2.2 The stack frame was different depending on the optimization. Tried without -O and with -O1. Got different structure of the stack frame.

Is there a way to backtrace interworked ARM/Thumb code, without using tpcs?

Thanx

Eli Stern

[Andrew Haley]

Post by Stern, Eli
I am using uClibc (as opposed to glibc), so the backtrace() functions do not exist.
I am trying to write a backtrace function, but cannot determine the stack frame for Thumb code, since it seems inconsistent.
1. Compiled using "-mtpcs-frame -mtpcs-leaf-frame". This creates a consistent stack frame, but is very expensive. It adds approximately 15 Thumb instructions per function.
2. Compiled using "-fno-omit-frame-pointer". There were 2 problems here.
2.1 When returning from main(), I did not reach a NULL fp.
2.2 The stack frame was different depending on the optimization. Tried without -O and with -O1. Got different structure of the stack frame.
Is there a way to backtrace interworked ARM/Thumb code, without using tpcs?

I'd have a look at using _Unwind_Backtrace, which is in libgcc.
You'll have to compile with full unwinder data and link with
--no-merge-exidx-entries. I think the unwinder should be able to cope
with a mixture of Thumb and ARM frames.

Andrew.

[Stern, Eli]

Tried to read a bit about this (unwind). Not much documentation available.
Seems it was not created for this purpose.
Couldn't figure out exactly how to use it.

Also, it will add quite a large table of data for each function, thus making the total memory consumption larger.

Wouldn't it make more sense to "convince" the compiler to produce a consistent Thumb stack frame?
Note that the ARM and Thumb stack frames do not have to be identical, since it is possible to differentiate between ARM and Thumb code using the LSBit of the return address.
So if I get a consistent ARM FP and a consistent Thumb FP, I can traverse the stack.

Eli Stern

-----Original Message-----
From: Andrew Haley [mailto:***@redhat.com]
Sent: Monday, July 26, 2010 12:11 PM
To: Stern, Eli
Cc: gcc-***@gcc.gnu.org
Subject: Re: Stack backtrace for ARM/Thumb

...

I'd have a look at using _Unwind_Backtrace, which is in libgcc.
You'll have to compile with full unwinder data and link with
--no-merge-exidx-entries. I think the unwinder should be able to cope
with a mixture of Thumb and ARM frames.

Andrew.

[Andrew Haley]

Post by Stern, Eli
Tried to read a bit about this (unwind). Not much documentation available.
Seems it was not created for this purpose.

It certainly was!
I know, because I wrote it. :-)

Post by Stern, Eli
Couldn't figure out exactly how to use it.
Also, it will add quite a large table of data for each function, thus making the total memory consumption larger.
Wouldn't it make more sense to "convince" the compiler to produce a consistent Thumb stack frame?

I have no idea why you think so. For exceptions we have
the unwinder data, so we don't need fully-linked stack frames.

I'm not really sure why tpcs frames are so expensive, though.

Andrew.

Post by Stern, Eli
Note that the ARM and Thumb stack frames do not have to be identical, since it is possible to differentiate between ARM and Thumb code using the LSBit of the return address.
So if I get a consistent ARM FP and a consistent Thumb FP, I can traverse the stack.
Eli Stern
-----Original Message-----
Sent: Monday, July 26, 2010 12:11 PM
To: Stern, Eli
Subject: Re: Stack backtrace for ARM/Thumb
...
I'd have a look at using _Unwind_Backtrace, which is in libgcc.
You'll have to compile with full unwinder data and link with
--no-merge-exidx-entries. I think the unwinder should be able to cope
with a mixture of Thumb and ARM frames.
Andrew.