I'm seeing differences between the DWARF data being generated by gcc 3.4.6 and
4.1.2.
Compiling the following (-g -mno-quickcall):
int f(int a)
{
return a;
}
generates the following code (in both 3.4.6 and 4.1.2):
00000000 <_f>:
0: 6d f6 mov.w r6,@-r7
2: 0d 76 mov.w r7,r6
00000004 <.LM2>:
4: 6f 62 00 04 mov.w @(0x4:16,r6),r2
00000008 <.LM3>:
8: 0d 20 mov.w r2,r0
a: 6d 76 mov.w @r7+,r6
c: 54 70 rts
But, looking at the DWARF data, this is what 3.4.6 produces:
<1><38>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_name : f
DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6)
<2><4d>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : a
DW_AT_location : 2 byte block: 91 4 (DW_OP_fbreg: 4)
This means variable 'a' can be found at the address contained in r6 (frame
pointer) + 4, right? Both gdb and our internal debugger recognizes this and
extracts the correct value for 'a'.
4.1.2, however, generates this:
<1><38>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_name : f
DW_AT_frame_base : 1 byte block: 57 (DW_OP_reg7)
<2><4d>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : a
DW_AT_location : 2 byte block: 91 0 (DW_OP_fbreg: 0)
which translates to the address contained in r7 (stack pointer) + 0. To me,
this does not make sense, as the stack pointer will point to the old frame
pointer (in this particular case). So loading the value from this address will
load the old frame pointer instead of 'a'. Needless to say, both gdb and our
own debugger has problems with this file; gdb doesn't even get a correct stack
trace.
--
Summary: [h8300] bad dwarf frame base data
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ekloef at virtutech dot com
GCC host triplet: i686-linux-gnu
GCC target triplet: h8300-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31934
