On 13/10/16 20:34, Jason Merrill wrote:
> On Tue, Oct 11, 2016 at 9:39 AM, Jakub Jelinek <ja...@redhat.com> wrote:
>
>> And, as mentioned in the DWARF mailing list, I think we should emit
>> DW_AT_inline on the inline vars (both explicit and implicit - static
>> constexpr data members in C++17 mode). I hope that can be done as a
>> follow-up.
>
> Makes sense.
>
As I write this I have been waiting for my registration email for the
DWARF mailing list, so I havent seen the email you sent.
I was wondering whether the regressions I'm picking up for
arm-none-eabi-gdb are related to the change in behavior you are
suggesting. These are the fails:
$9 = {static s = 10, _vptr.A = 0xbb14 <vtable for A+8>, c = 120 'x', j =
33, jj = 1331, s = 47892}^M
(gdb) FAIL: gdb.cp/member-ptr.exp: print a (j = 33)
...
$12 = {static s = 10, _vptr.A = 0xbb14 <vtable for A+8>, c = 120 'x', j
= 44, jj = 1331, s = 47892}^M
(gdb) FAIL: gdb.cp/member-ptr.exp: print a (j = 44)
The logs used to read:
$9 = {_vptr.A = 0xbb44 <vtable for A+8>, c = 120 'x', j = 33, jj = 1331,
static s = 10}^M
(gdb) PASS: gdb.cp/member-ptr.exp: print a (j = 33)
...
$12 = {_vptr.A = 0xbb44 <vtable for A+8>, c = 120 'x', j = 44, jj =
1331, static s = 10}^M
(gdb) PASS: gdb.cp/member-ptr.exp: print a (j = 44)
As you see the Classe's structure has changed.
After bisecting GCC it does seem it's this patch that causes the change
in debug information.
I did the following to inspect the debug information (renaming A to
BANANA, to make it easier to search):
$ cp src/binutils-gdb/gdb/testsuite/gdb.cp/member-ptr.cc t.c
$ sed -i "s/A/BANANA/g" t.c
$ arm-none-eabi-g++ -c -g -mthumb -mcpu=cortex-m3 t.c
$ arm-none-eabi-g++ t.o -g -lm -specs=rdimon.specs -lc -lg -lrdimon
-mthumb -mcpu=cortex-m3
$ arm-none-eabi-readelf -wi a.out
Before this patch you see BANANA's first DW_TAG_MEMBER is '_vptr.BANANA'
and there is only one DW_TAG_MEMBER entry for the 'static s'.
Whereas after this patch you see the first DW_TAG_MEMBER is:
<2><8be>: Abbrev Number: 34 (DW_TAG_member)
<8bf> DW_AT_name : s
<8c1> DW_AT_decl_file : 1
<8c2> DW_AT_decl_line : 40
<8c3> DW_AT_type : <0x5d>
<8c7> DW_AT_external : 1
<8c7> DW_AT_accessibility: 1 (public)
<8c8> DW_AT_declaration : 1
the 'static s' that used to be the last, followed by '_vptr.BANANA' and
its last DW_TAG_MEMBER is:
<2><8f5>: Abbrev Number: 38 (DW_TAG_member)
<8f6> DW_AT_specification: <0x8be>
<8fa> DW_AT_linkage_name: (indirect string, offset: 0x4a0):
_ZN6BANANA1sE
<8fe> DW_AT_location : 5 byte block: 3 64 bf 1 0
(DW_OP_addr: 1bf64)
I haven't tested it on other targets.
Is this expected behavior?
Regards,
Andre
