This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |