This is the mail archive of the
mailing list for the GDB project.
Re: ARM prologue parsing support for Thumb-2 instructions?
- From: Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb at sourceware dot org, Richard Earnshaw <rearnsha at arm dot com>, dan at codesourcery dot com
- Date: Mon, 19 Jul 2010 09:51:17 +0100
- Subject: Re: ARM prologue parsing support for Thumb-2 instructions?
- References: <201007161703.o6GH3XoP011062@d12av02.megacenter.de.ibm.com>
On Fri, 2010-07-16 at 18:03 +0100, Ulrich Weigand wrote:
> in testing GDB on an armv7l-linux-gnueabi board running Ubuntu
> I noticed serious problems with getting backtraces out of system
> Looking into this, it turns out that arm_analyze_prologue appears to
> 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
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
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
> Since Thumb-2 is the default code generation option on this system,
> makes it just about impossible to backtrace out of any code that does
> 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
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:
Principal Engineer - PDSW Tools