[RFC] Possible gcc/DWARF or gdb/DWARF problem
Jim Blandy
jimb@redhat.com
Mon Dec 1 15:21:00 GMT 2003
Fred Fish <fnf@public.ninemoons.com> writes:
> For reference, here are the relevant parts of the dwarfdump output:
>
> <1>< 107> DW_TAG_base_type
> DW_AT_name signed char
> DW_AT_byte_size 1
> DW_AT_encoding DW_ATE_signed_char
>
> <2>< 160> DW_TAG_variable
> DW_AT_name l
> DW_AT_decl_file 1 /tmp/b.c
> DW_AT_decl_line 8
> DW_AT_type <107>
> DW_AT_location DW_OP_fbreg 0
>
> I'd like to get some comments on whether this is a gcc/DWARF or
> gdb/DWARF issue. If the consensus is that gdb is not doing the right
> thing, then I'll chase the problem in gdb. If the consensus is that
> it is gcc, then I'll file a formal gcc bug report. My guess is that
> since gcc is generating the memory offset of a 1 byte object relative
> to the frame pointer that the DW_AT_location for the big endian case
> should be:
>
> DW_AT_location DW_OP_fbreg 3
So, in the big-endian case, the compiler is generating code that
places the one-byte value at offset 3 from the frame base register.
(Since you say the code for the little-endian and big-endian cases is
identical, we know it uses 32-bit stores and loads to fb+0 to access
it, but that's irrelevant; it's a one-byte value.) Right?
You're right --- GCC is wrong. The Dwarf 2 info it's producing
clearly describes a one-byte value at offset 0 from the frame base.
How GCC decides to generate code to access it is not our problem.
More information about the Gdb
mailing list