[Bug c/82509] New: DW_AT_endianity issues with attribute scalar_storage_order
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.
[Bug debug/82509] DW_AT_endianity issues with attribute scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509 --- Comment #3 from Peeter Joot --- Created attachment 42350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42350&action=edit test case used to verify Eric's patch in a gdb session.
[Bug debug/82509] DW_AT_endianity issues with attribute scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509
--- Comment #4 from Peeter Joot ---
Here's the debug session that shows the compiler+debugger stack playing nicely
together:
(gdb) n
40 int cb = memcmp( &b, &n, sizeof( b ) );
(gdb) p bt
$1 = {v = 3, a = {1, 2, 3, 4}}
(gdb) p b
$2 = {v = 3, a = {1, 2, 3, 4}}
(gdb) p n
$3 = {v = 3, a = {1, 2, 3, 4}}
(gdb) p lt
$4 = {v = 3, a = {1, 2, 3, 4}}
(gdb) p l
$5 = {v = 3, a = {1, 2, 3, 4}}
(gdb) p bt.v = 4
$6 = 4
(gdb) p bt
$7 = {v = 4, a = {1, 2, 3, 4}}
(gdb) x/4x &bt
0x7fffd32c: 0x0400 0x02000100 0x04000300 0x
(gdb) x/4x <
0x7fffd308: 0x0003 0x00020001 0x00040003 0x0003
(gdb) q
This uses your patch to gcc, plus the following patch to gdb:
https://sourceware.org/ml/gdb-patches/2017-10/msg00266.html
