This is the mail archive of the
mailing list for the GDB project.
Re: ARM prologue parsing support for Thumb-2 instructions?
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: matthew dot gretton-dann at arm dot com (Matthew Gretton-Dann)
- Cc: gdb at sourceware dot org, rearnsha at arm dot com (Richard Earnshaw), dan at codesourcery dot com
- Date: Mon, 19 Jul 2010 12:59:05 +0200 (CEST)
- Subject: Re: ARM prologue parsing support for Thumb-2 instructions?
Matthew Gretton-Dann wrote:
> 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
Actually, it seems I misspoke here; I intended to refer to arm_scan_prologue
where I wrote arm_analyze_prologue. GDB is in fact then calling down to
thumb_analyze_prologue, not arm_analyze_prologue, in my test. So at least
in the test case I'm looking at, instruction state detection does not appear
to be the problem ...
> 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
Thanks for the tip. This patch did go upstream a while ago and is
already included in the pre-7.2 GDB I was testing.
> Trunk thumb_analyze_prologue does have support for Thumb-2.
Well, all the support for Thumb-2 I can see is in this block:
else if ((insn & 0xe000) == 0xe000 && cache == NULL)
/* Only recognize 32-bit instructions for prologue skipping. */
which, as the comment says, is active *only* if this routine is
called from arm_skip_prologue (with cache == NULL), but not if the
routine is called from arm_scan_prologue (with cache != NULL),
which is what is used during unwinding.
> 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.
That may or may not be an additional problem; right now during unwinding
GDB doesn't even get beyond the very first instruction of a Thumb-2
> 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.
OK, I'll have a look.
> 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:
Thanks for the pointer!
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE