[Bug c/82509] New: DW_AT_endianity issues with attribute scalar_storage_order

["peeterjoot at protonmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509

            Bug ID: 82509
           Summary: DW_AT_endianity issues with attribute
                    scalar_storage_order
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: peeterjoot at protonmail dot com
  Target Milestone: ---

Created attachment 42336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42336&action=edit
code using scalar_storage_order attribute

The attached code only ends up with DW_AT_endianity dwarf attributes when no
typedefs are used.

Example:


~/gcc8/bin/gcc -g test.c -o mixed
~/gcc8/bin/gcc -g bewtypedef.c -o bewtypedef -DWITH_TYPEDEFS
~/gcc8/bin/gcc -g bewtypedef.c -o bentypedef

/bin/eu-readelf --debug-dump bewtypedef |grep -i endian

[no output]

/bin/eu-readelf --debug-dump bentypedef |grep -i endian
             endianity            (data1) 1
             endianity            (data1) 1
          attr: endianity, form: data1, offset: 0xda
          attr: endianity, form: data1, offset: 0xe7

Consistent availability of the DW_AT_endianity attributes would allow gdb (or
other debuggers) to display non-native endian members to show these fields with
values that match their intended use, instead of showing their representation.

There is an additional problem with the DW_AT_endianity attributes with respect
to gdb specifically.  gdb does not have any infrastructure to have variations
of types, and builds a single 'struct type' that represents a given type (such
as int, short, ...).

For this reason, I would suggest that gcc use an alternate DW_AT_name for any
type that has non-native endianity.  For example, in:

struct other {
    int v;
    short a[4];
} 
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
__attribute__( ( scalar_storage_order( "big-endian" ) ) )
#else
__attribute__( ( scalar_storage_order( "little-endian" ) ) )
#endif
;

gcc could use DW_AT_name's of "int.be" and "short.be" respectively instead of
"int" and "short" for the members v, and a above (assuming a little endian
target).  This would allow gdb to display both native and non-native endianity
int and short variables.  Right now, if the DW_AT_endianity information is
pushed into gdb's struct type, the debugged program can have only one of the
native or non-native representations in the debugger session.  

A gdb patch with preliminary experimental support for DW_AT_endianity can be
found here: https://sourceware.org/ml/gdb-patches/2017-10/msg00145.html

It could be argued not being able to encode additional attributes in the gdb
type representation is a bug in gdb, but given that gdb and gcc should play
nicely together, it seems reasonable to me to use an alternate DW_AT_name when
emitting the dwarf info for code using the scalar_storage_order attribute.