RE: arm-aout vs arm-elf

[David Korn <dkorn at pixelpower dot com>]

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

  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.


      DaveK
-- 
Burn your ID card!  http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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