Re: [RFC] Possible gcc/DWARF or gdb/DWARF problem

[Jim Blandy <jimb@redhat.com>]

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.