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

["Ulrich Weigand" <uweigand@de.ibm.com>]

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
> correctly.

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
> single-stepping.  

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.

> 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.

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
prologue ...

> 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:
> http://sourceware.org/ml/libc-ports/2010-04/msg00001.html.

Thanks for the pointer!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com