Hi,
Well, as I keep on munching on the internals of newlib, and debugging
the problems I'm having with my code, I've discovered another sad
issue that I don't quite know how to overcome. May be the new gcc will
fix this.
The problem is that the dwarf debugging tables don't match the stack
frame of the function. I'm compiling trace.c, and I did remove all the
flags, and left "-O0 -g" only (along with all the -mwin32, and
-march). Here is the piece of the objdump -W -G -l -d -g on the object
file.
Section that defines the "len" local variable from trace.o
<2><39f>: Abbrev Number: 16 (DW_TAG_variable)
<3a0> DW_AT_name : len
<3a4> DW_AT_decl_file : 1
<3a5> DW_AT_decl_line : 147
<3a6> DW_AT_type : <0x90>
<3aa> DW_AT_location : 2 byte block: 91 5c (DW_OP_fbreg: -36)
Section that defines the "len" local variable from cegcc.dll has the
same like one above, but also has another one, without DW_AT_location:
<3><e1e1>: Abbrev Number: 29 (DW_TAG_variable)
<e1e2> DW_AT_name : len
<e1e6> DW_AT_decl_file : 1
<e1e7> DW_AT_decl_line : 147
<e1e8> DW_AT_type : <0xd61b>
This is the code that assigns the result of sprintf to that "len" local variable
/root/ws/cegcc/cegcc/src/newlib/newlib/libc/sys/wince/trace.c:143
5e494: e1a0c00d mov ip, sp
5e498: e92d000e push {r1, r2, r3}
5e49c: e92dd810 push {r4, fp, ip, lr, pc}
5e4a0: e24cb010 sub fp, ip, #16 ; 0x10
5e4a4: e24dde77 sub sp, sp, #1904 ; 0x770
5e4a8: e50b0770 str r0, [fp, #-1904]
[ skipped ]
/root/ws/cegcc/cegcc/src/newlib/newlib/libc/sys/wince/trace.c:154
364: eb000000 bl 8 <GetTickCount+0x8>
368: e1a0e000 mov lr, r0
36c: e3e03ddf mvn r3, #14272 ; 0x37c0
370: e2433037 sub r3, r3, #55 ; 0x37
374: e5933000 ldr r3, [r3]
378: e1a0c003 mov ip, r3
37c: e24b3e46 sub r3, fp, #1120 ; 0x460
380: e2433002 sub r3, r3, #2 ; 0x2
384: e24b2062 sub r2, fp, #98 ; 0x62
388: e58d2000 str r2, [sp]
38c: e1a00003 mov r0, r3
390: e59f1308 ldr r1, [pc, #776] ; 6a0 <__WCETrace+0x394>
394: e1a0200e mov r2, lr
398: e1a0300c mov r3, ip
39c: eb000000 bl 8 <sprintf+0x8>
3a0: e1a03000 mov r3, r0
3a4: e50b3020 str r3, [fp, #-32]
So the debugging section declares len as (fp-36), but the code uses
offset (fp-32)
The debugger seems to be off not by 4 bytes:
(gdb) print $fp - (int)(&len)
$20 = 0x14
Not sure how did it ever arrive to decide it's (fp-20), but may be
that's because the offset for the arguments is 16, so 20 would be the
offset of first local variable, but that's a wild wild guess. All
other variables are shifted 12 bytes. May be it's using (-20) instead
of (-36) because of that other secondary definition of the local var
in the debug section that has no location data.
objdump also seem to not be that reliable in decoding dwarf sections
(there are warning messages). dwarfdump didn't help at all, as it
doesn't seem to comprehend the PE format.
Very annoying, have to say. Especially since I couldn't suspect
anything like that and turned a lot of other stones over first.
The code seems to be correct, it's only the debugging symbols that
seem to be off (at least to my recent observations).
Thanks,
Pawel.
--
With best of best regards
Pawel S. Veselov
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
