Re: ARM prologue parsing support for Thumb-2 instructions?

[Matthew Gretton-Dann <matthew.gretton-dann@arm.com>]

Ulrich,

On Fri, 2010-07-16 at 18:03 +0100, Ulrich Weigand wrote:
> Hello,
> 
> in testing GDB on an armv7l-linux-gnueabi board running Ubuntu
> Maverick
> I noticed serious problems with getting backtraces out of system
> libraries.
> 
> Looking into this, it turns out that arm_analyze_prologue appears to
> have
> no support at all for decoding Thumb-2 instructions.  (There is some
> support for Thumb-2 in arm_skip_prologue, but not for unwinding.)

If gdb is using arm_analyze_prologue and not thumb_analyze_prologue for
Thumb (1 or 2) code then gdb is not guessing the instruction state
correctly.

I submitted a patch earlier this year
(http://sourceware.org/ml/gdb-patches/2010-03/msg00168.html) to try to
improve gdb's heuristic for determining the instruction state which may
help - although in that particular use case it was for
single-stepping.  

Note though that it may just not be possible to make a 100% accurate
statement without some form of debugging symbols present - just mapping
symbols ($a, $d, $t) would be enough for determining the instruction
set.

> Since Thumb-2 is the default code generation option on this system,
> this
> makes it just about impossible to backtrace out of any code that does
> not
> come with debug information.

Trunk thumb_analyze_prologue does have support for Thumb-2.  However,
thumb_analyze_prologue will stop analyzing the prologue as soon as it
sees an instruction which it does not understand as part of a prologue
sequence.  This is the opposite from arm_analyze_prologue, which knows
which non-prologue sequence instructions are safe to ignore and which
are not.

Fixing thumb_analyze_prologue to behave like arm_analyze_prologue is on
my list of things to do, but it is not going to happen immediately.  So
if you want to have a go at fixing this please feel free.

A related issue with backtracing through system calls is that inline
syscalls in glibc corrupt the frame pointer (during the syscall) so that
if you try to backtrace when at a syscall you get garbage.  This was
fixed in this glibc patch:
http://sourceware.org/ml/libc-ports/2010-04/msg00001.html.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd