[RFA/RFC] ARM : one-line prologue analysis

[Jerome Guitton <guitton at act-europe dot fr>]

The support for unwinding through functions which do not build a frame
pointer seems broken for arm-elf. Consider the attached example. It is
basically main -> c -> b -> a (X '->' Y meaning "X calls Y"). the
calls to printf are here only to avoid sibcall optimization. With gcc
3.2, we will get a one-line prologue for a, b, c and main :


a:
        str     lr, [sp, #-4]!
	[...]

Alas, getting a backtrace from 'a' will not work properly:

(gdb) file d
Reading symbols from d...done.
(gdb) target sim
Connected to the simulator.
(gdb) load d
[...]
(gdb) b a
Breakpoint 1 at 0x8228: file a.c, line 5.
(gdb) r
Starting program: /cardiff.a/guitton/fsf/gdb-head-merge/tmp/test/d 

Breakpoint 1, a () at a.c:5
5         printf ("HERE I AM J.H.");
(gdb) bt
#0  a () at a.c:5
#1  0x00824000 in ?? ()

There is a 'address minus one' thing going on. Indeed, 0x00824000 is not a
valid address, it should be 0x00008240:

(gdb) x/i 0x00008240
0x8240 <b+8>:   ldr     r0, [pc, #8]    ; 0x8250 <b+24>

This problem is in arm_make_prologue_cache. Indeed, for testing if a
register has been saved on the stack, arm_make_prologue_cache should
compare the field addr of the saved reg table to -1, according to
trad-frame.h.  It compare it to 0! That's where the 'address minus -1'
thing comes from.

The first patch is a fix for this bug (obv.dif). It seems straight forward
to me. I run the gdb testsuite on a arm-elf simulator, it fixes 150 failures.
No regression.

Still, there is another bug:

(gdb) bt
#0  a () at a.c:5
#1  0x00008240 in b () at b.c:4
#2  0x00008240 in b () at b.c:4

For some reason that I don't understand completely (and that's the
[RFC] part of this email), in arm_scan_prologue the choice has been
made not to get lr from the stack if the prologue is "str lr, [sp,
#4]!". I just want to point out that getting it from the stack (my
second patch, lr.dif) fixes the problem:

(gdb) bt
#0  a () at a.c:5
#1  0x00008240 in b () at b.c:4
#2  0x0000825c in c () at c.c:4
#3  0x00008278 in main () at d.c:2

I don't thing that's a good idea to consider that these one-line-prologue
functions are frameless, even if they don't build a frame pointer.
Opinions/ideas?

Tested against the testsuite on the arm simulator, I get no regression and
no fix. (the baseline debugger includes my first patch)

-- 
Jerome

Attachment: obv.dif
Description: Text document

Attachment: lr.dif
Description: Text document

Attachment: example.txt
Description: Text document