char[] chars;
void main()
{
string lok = "Something";
chars = "Anything".dup;
}
compiled dmd -g
mk@bid:~/work/pokus/debug$ gdb ./locals
GNU gdb (GDB) 7.8.50.20141030-cvs
(gdb) b 6
Breakpoint 1 at 0x8064e88: file locals.d, line 6.
(gdb) r
Starting program: /home/mk/work/pokus/debug/locals
Breakpoint 1, D main () at locals.d:6
6 chars = "Anything".dup;
(gdb) info locals
lok = <error reading variable>
This is with Ian's patched gdb on linux x86
dmd 2.066 works and 2.067a -gc works too.
Debug info (2.066 vs 2.067a) looks the same.
I haven't tested patched gdb + x86_64
I suspect this may be a gdb problem or something botched up on my side, but I don't have time for more testing now.
Confirmed, doesn't depend on ld.bfd vs. ld.gold.
Neither dwarfdump nor readelf --debug-dump report any error.
Comment #5 by code — 2015-03-04T04:38:59Z
.debug_frame and .debug_ranges changed and look indeed weird.
There is an overlapping PC range.
000000c0 0000000000000024 00000000 FDE cie=00000000 pc=0000000000000000..0000000000000084
DW_CFA_advance_loc: 1 to 0000000000000001
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r6 (rbp) at cfa-16
DW_CFA_advance_loc: 2 to 0000000000000003
DW_CFA_def_cfa_register: r6 (rbp)
DW_CFA_advance_loc: 6 to 0000000000000009
DW_CFA_offset: r1 (rdx) at cfa-80
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
000000e8 0000000000000024 00000000 FDE cie=00000000 pc=0000000000000000..0000000000000053
DW_CFA_advance_loc: 1 to 0000000000000001
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r6 (rbp) at cfa-16
DW_CFA_advance_loc: 2 to 0000000000000003
DW_CFA_def_cfa_register: r6 (rbp)
DW_CFA_advance_loc: 6 to 0000000000000009
DW_CFA_offset: r1 (rdx) at cfa-24
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
00000000 0000000000000000 0000000000000084
00000000 0000000000000000 0000000000000053
Further investigation tomorrow ;).
Comment #6 by bugzilla — 2015-03-09T09:46:11Z
Any news?
Comment #7 by code — 2015-03-09T22:28:12Z
For yet unknown reason gdb reads an incorrect sizeof for the .length variable of the string. This only applies to the arrays in main not the ones passed to the dup functions.
It also works in lldb.
It would be more optimal if dmd cached and emitted only a single instance per array type. Will try to implement that and see if it helps before spending more hours debugging gdb.
Comment #8 by code — 2015-03-09T23:49:48Z
(In reply to Martin Nowak from comment #7)
> It would be more optimal if dmd cached and emitted only a single instance
> per array type. Will try to implement that and see if it helps before
> spending more hours debugging gdb.
Indeed, fixing the type repetition of debug infos for arrays fixes the issue.
The code is pretty ugly and needs some refactoring before fixing the incorrect hashing, but that'd be my preferred fix as it get's rid of a lot of unnecessary debug info.
Comment #9 by bugzilla — 2015-03-11T23:01:56Z
(In reply to Martin Nowak from comment #8)
> Indeed, fixing the type repetition of debug infos for arrays fixes the issue.
> The code is pretty ugly and needs some refactoring before fixing the
> incorrect hashing, but that'd be my preferred fix as it get's rid of a lot
> of unnecessary debug info.
What is the prospect of this being done in time for 2.067?
Comment #10 by code — 2015-03-13T17:42:39Z
(In reply to Walter Bright from comment #9)
> What is the prospect of this being done in time for 2.067?
I'm working on that, but dwarf.c is a mess. So far everything I tried had to touch too much code, likely resulting in a regression.
I think the simplest solution is to throw out DW_AT_siblings, it's not that useful anyhow.
Comment #11 by code — 2015-03-13T22:12:11Z
OK, found it. For TYref we set the pointer byte_size to -1.
Wondering why we're emitting TYref for arrays though.