ARM prologue parsing support for Thumb-2 instructions?

ARM prologue parsing support for Thumb-2 instructions?

[Ulrich Weigand]

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

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.

Now I was wondering whether I'm missing something here ...  Is this really
just something that's simply missing?  If so, do you know whether anybody
is currently working on adding this support?  Otherwise, I could give it
a try.

Thanks,
Ulrich

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

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

[Daniel Jacobowitz]

On Fri, Jul 16, 2010 at 07:03:33PM +0200, Ulrich Weigand wrote:
> 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.
> 
> Now I was wondering whether I'm missing something here ...  Is this really
> just something that's simply missing?  If so, do you know whether anybody
> is currently working on adding this support?  Otherwise, I could give it
> a try.

In my personal opinion, having no debug info - not even just
.debug_frame - for system libraries is a mistake.

That said, I don't think you're missing anything; and I don't know of
anyone working on Thumb-2 prologue analysis.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Matthew Gretton-Dann]

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

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

[Ulrich Weigand]

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

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

[Daniel Jacobowitz]

On Mon, Jul 19, 2010 at 12:59:05PM +0200, Ulrich Weigand wrote:
> > 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.

IIRC, it would not be hard to fill in the missing pieces; I just
didn't need them at the time, and could not easily test them.  So
rather than risk them being wrong, I left them for later.

-- 
Daniel Jacobowitz
CodeSourcery