arm-aout vs arm-elf

[Quality Quorum]

On Mon, 15 Oct 2001, David Korn wrote:

>
> >BTW, I tracked down another arm-specific problem with gcc-2.95.3 (thanks
> >to Keith Seitz). This version generates debug info with incorrect address
> >for the first line of the function (below is a result of objdump):
>
> >00008040 <_xxx>:
> >_xxx():
> >    8040:       e1a0c00d        mov     ip, sp
> >    8044:       e92dd800        stmdb   sp!, {fp, ip, lr, pc}
> >    8048:       e24cb004        sub     fp, ip, #4      ; 0x4
> >    804c:       e24dd014        sub     sp, sp, #20     ; 0x14
> >/home/aromanov/tst/xxx.c:7
> >    8050:       e50b0010        str     r0, [fp, -#16]
> >    8054:       e50b1014        str     r1, [fp, -#20]
> >    8058:       e50b2018        str     r2, [fp, -#24]
> >    805c:       e50b301c        str     r3, [fp, -#28]
> >/home/aromanov/tst/xxx.c:8
> >    8060:       e51b301c        ldr     r3, [fp, -#28]
> >    8064:       e58d3000        str     r3, [sp]
> >    8068:       e3a00001        mov     r0, #1  ; 0x1
> >    806c:       e51b1010        ldr     r1, [fp, -#16]
> >    8070:       e51b2014        ldr     r2, [fp, -#20]
> >    8074:       e51b3018        ldr     r3, [fp, -#24]
> >    8078:       eb000000        bl      8080 <_yyy>
> >/home/aromanov/tst/xxx.c:9
> >    807c:       e91ba800        ldmdb   fp, {fp, sp, pc}
>
>
> >Correct results (again thanks to Keith) is here:
> >
> >00008140 <xxx>:
> >xxx():
> >/home/keiths/tst/xxx.c:7
> >    8140:       e1a0c00d        mov     ip, sp
> >    8144:       e92dd800        stmdb   sp!, {fp, ip, lr, pc}
> >    8148:       e24cb004        sub     fp, ip, #4      ; 0x4
> >    814c:       e24dd014        sub     sp, sp, #20     ; 0x14
> >    8150:       e50b0010        str     r0, [fp, -#16]
> >    8154:       e50b1014        str     r1, [fp, -#20]
> >    8158:       e50b2018        str     r2, [fp, -#24]
> >    815c:       e50b301c        str     r3, [fp, -#28]
> >/home/keiths/tst/xxx.c:8
> >    8160:       e51b301c        ldr     r3, [fp, -#28]
> >    8164:       e58d3000        str     r3, [sp]
> >    8168:       e3a00001        mov     r0, #1  ; 0x1
> >    816c:       e51b1010        ldr     r1, [fp, -#16]
> >    8170:       e51b2014        ldr     r2, [fp, -#20]
> >    8174:       e51b3018        ldr     r3, [fp, -#24]
> >    8178:       eb000000        bl      8180 <yyy>
> >/home/keiths/tst/xxx.c:9
> >    817c:       e91ba800        ldmdb   fp, {fp, sp, pc}
>
> >As a result gdb incorrectly calculates breakpoint address for the
> >function, e.g. `b xxx' will set break point at 0x8050 in the
> >first case and at 0x8160. So, when break point is would be hit
> >gdb will print garbadge as passed parameter values.
>
>   This is the normal and correct behaviour, isn't it?  If you set a break
> on the start of a function, you get a break on the very start of that
> function, which permits you to step through the prologue code and check
> the initialisation of the stack frame.  If you set a breakpoint on the
> first line of the function, it doesn't break until after the stack frame
> is set up.  These are two different behaviours, both useful in their own
> conditions; it's a mistaken assumption on your part that one is 'right'
> and the other 'wrong'.

Ok, let us call one default.

It seems reasonable to expect that if did `b xxx', then I will get
properly printed arguments when break point is hit. If it does not,
it is a bug.

>
>   If you want a breakpoint on the first line of a function rather than at
> the very start, it would be better to set your breakpoint on the first
> line of the function, instead of fudging the compiler to emit incorrect
> debug data that claims the first line is at the start of the function and
> there is no function prologue.

Second example is compiled by gcc-3.0.1 and it prints correct values,
first example is compiled by gcc-2.95.3 and it prints garbage, so I
suppose that it should be considered a bug in gcc-2.95.3.

BTW, I see nothing wrong in stopping before argument copying is
complete, the only thing to worry about in order to properly print
arguments will be an ability of gdb to interperet apcs-32.

>
>
>       DaveK

Thanks,

Aleksey



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com