[Bug debug/82509] DW_AT_endianity issues with attribute scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-10-11
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou ---
> 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
Indeed, the code is correct but not the debug info in this case.
> 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.
The decision was made to use strict DWARF and we'll stick to it I think.
> 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
Great, thanks for working on this.
> 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.
Custom encoding are necessary when the debug info format lacks expressiveness
but this is not the case here so IMO GDB will have to bite the bullet.
[Bug debug/82509] DW_AT_endianity issues with attribute scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[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
[Bug debug/82509] DW_AT_endianity issues with attribute scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509 --- Comment #5 from Eric Botcazou --- > This uses your patch to gcc, plus the following patch to gdb: > > https://sourceware.org/ml/gdb-patches/2017-10/msg00266.html Great, thanks for the testing.
[Bug debug/82509] DW_AT_endianity issues with attribute scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509 --- Comment #6 from Eric Botcazou --- Author: ebotcazou Date: Thu Oct 19 13:50:10 2017 New Revision: 253893 URL: https://gcc.gnu.org/viewcvs?rev=253893&root=gcc&view=rev Log: PR debug/82509 * dwarf2out.c (new_die_raw): New static inline function. (new_die): Use it to create the DIE. (add_AT_external_die_ref): Likewise. (clone_die): Likewise. (clone_as_declaration): Likewise. (dwarf2out_vms_debug_main_pointer): Likewise. (base_type_die): Likewise. Remove early return for corner cases. Do not call add_pubtype on the DIE here. (is_base_type): Remove ERROR_MARK and return 0 for VOID_TYPE. (modified_type_die): Adjust the lookup for reverse order DIEs. Skip typedefs for base types with DW_AT_endianity. Make sure a DIE with native order exists for base types, attach the DIE manually and call add_pubtype on it. Do not equate a reverse order DIE to the type. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/sso-1.c - copied unchanged from r253848, trunk/gcc/testsuite/gcc.dg/debug/dwarf2/sso.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/sso-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/sso-3.c Removed: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/sso.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/82509] DW_AT_endianity issues with attribute scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #7 from Eric Botcazou --- Fixed on mainline.
