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.