[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Tue Jan 17 18:32:13 2017 New Revision: 244545 URL: https://gcc.gnu.org/viewcvs?rev=244545&root=gcc&view=rev Log: PR debug/78839 * dwarf2out.c (field_byte_offset): Restore the PCC_BITFIELD_TYPE_MATTERS behavior for INTEGER_CST DECL_FIELD_OFFSET and DECL_FIELD_BIT_OFFSET. Use fold_build2 instead of build2 + fold. (analyze_variants_discr, gen_variant_part): Use fold_build2 instead of build2 + fold. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-11 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #11 from Jakub Jelinek --- Created attachment 40505 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40505&action=edit gcc7-pr78839.patch There were actually numerous bugs in that commit in the field_byte_offset routine. is_bit_offset_cst and is_byte_offset_cst vars were set to values that is the opposite of their names, then the whole PCC_BITFIELD_TYPE_MATTERS block was actually never entered, because there was: if (is_bit_offset_cst) return NULL; #ifdef PCC_BITFIELD_TYPE_MATTERS /* We used to handle only constant offsets in all cases. Now, we handle properly dynamic byte offsets only when PCC bitfield type doesn't matter. */ if (PCC_BITFIELD_TYPE_MATTERS && is_byte_offset_cst && is_bit_offset_cst) and after the first if is_bit_offset_cst thus was always false. But even with that fixed, the whole block computed something that has been just ignored. So, let's fix this first, then as incremental separately tested patch also use DECL_BIT_FIELD_REPRESENTATIVE if possible, and lastly for DWARF-4 and later we actually shouldn't be emitting for bitfields DW_AT_data_member_location and DW_AT_byte_size and DW_AT_bit_offset attributes at all, we should emit DW_AT_data_bit_offset (PR71669) instead of those. As GDB just gained DW_AT_data_bit_offset support last November, I'll for now use it only for -gdwarf-5 (which requires latest GDB anyway).
[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #10 from Tom O'Connor --- In regards to GDB, I noticed that when using a macro to get the offset for these bitfields, with objects built by both GCC 5 and earlier as well as GCC 6, I always get 0. For example: (gdb) macro define offsetof(t, f) &((t *) 0)->f) (gdb) p offsetof(struct s, type) $1 = (unsigned int *) 0x0 Historically, prior to GCC 6, this always matched up with DWARF's DW_AT_data_member_location value for bitfields. Yes, I see how GCC 6's combination of data_member_location and bit_offset can be combined to reach the true location. Historically, my use case has used the data_member_location value to get me the offset into say a raw memory image, for where to start reading data from a field of a structure in memory; I'd do bitfield shifts after reading from the aligned offset as reported in the DWARF structure. If using DECL_BIT_FIELD_REPRESENTATIVE as data_member_location is nicer and doesn't break the Ada use case, I'd be all for that. But if what's currently being emitted by GCC 6 is considered "more correct" than what previous versions had emitted, then I'll have to adjust. I only noticed the change between 5 and 6 once I started seeing odd results with the same code built by different GCCs.
[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com --- Comment #9 from Pierre-Marie de Rodat --- (In reply to Jakub Jelinek from comment #7) > The behavior changed with r231762, I haven't looked (yet) into details if it > is valid or not and why that changed. I haven’t had a look yet neither… bit addressing is hard. ;-) All I can do for now is to give some context for r231762: this commit tried to handle fields with dynamic sizes/positions but only with a focus on the ones at least byte-aligned. My playground for this was discriminated types in Ada, and I’m not sure these can be bit-packed (i.e. using sub-byte addressing). So if anything changed for bitfields, that was not intentional and can likely be fixed as long as it does not break things for the Ada types I tested. By the way, if one wants to see what I used for testing, here it is: https://github.com/pmderodat/dwarf-ada-testsuite/.
[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||pmderodat at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- So, first of all, it seems gdb handles this as expected no matter if it is the debug info emitted by GCC 5 or 6+. Say for protocol field, data_member_location is either 0 and bit_offset 16, or data_member_location 1 and bit_offset 24 and the type is unsigned int in each case and little endian. So it is either bits 16-24 in unsigned int starting at offset 0, or bits 24-32 at unsigned int starting at offset 1, that is the same thing. So the question is why does it matter to you? Though, I'd think it might be nicer to use byte_position of DECL_BIT_FIELD_REPRESENTATIVE as data_member_location (so data_member_location 0 in this case).
[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|other |debug Target Milestone|--- |6.4 Summary|DWARF output different |[6/7 Regression] DWARF |between GCC 5 and 6 |output different between ||GCC 5 and 6 --- Comment #7 from Jakub Jelinek --- The behavior changed with r231762, I haven't looked (yet) into details if it is valid or not and why that changed.