Comment #0 by erikas.aubade — 2014-09-22T08:29:51Z
It appears that, when compiling for x86_64 on linux, if invoked with a module besides the one containing main() first on the command line, DMD slightly messes up something with debug info, making it not possible to read some variables at runtime.
I've managed to make the problem work with the following setup, requiring two files; main.d and afunc.d.
main.d:
module main;
import afunc;
void main() {
size_t count;
while(true) {
count = inc(count);
}
}
afunc.d:
module afunc;
auto inc (size_t var) {
return ++var;
}
Compiling it with the following command:
$ dmd -m64 -g -ofbadsymbols afunc.d main.d
Load it in gdb with the following:
$ gdb ./badsymbols
then, in gdb, enter the following commands:
) break main.d:8
) run
here, it should run momentarily, then hit the breakpoint.
) print count
will give the error:
'Could not find the frame base for "D main".'
However, if you compile with this command instead:
$ dmd -m64 -g -ofgoodsymbols main.d afunc.d
then repeat the procedure, print count will show
'$1 = 0'
as expected.
Comment #1 by hsteoh — 2014-09-23T02:28:21Z
Unable to reproduce problem on Debian Linux / x86_64. I get $1 = 0 for `print count` in both goodsymbols and badsymbols. What version of gdb are you using?
Comment #2 by erikas.aubade — 2014-09-23T04:34:58Z
My gdb reports 'GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu'
Comment #3 by hsteoh — 2014-09-23T04:46:25Z
Hmm, I'm using gdb 7.7.1, and I don't see this problem.
Oh, btw, what version of dmd are you running? That's probably the more likely cause of the problem.
Comment #4 by erikas.aubade — 2014-09-23T04:59:25Z
I've had the issue with 2.065, 2.066, and 2.066.1-rc2.
Are you compiling 64-bit executables? I don't have the problem when I compile into 32bit mode.
Comment #5 by hsteoh — 2014-09-23T05:14:30Z
I'm compiling with -m64, as you indicated in the bug report. Don't see the problem.
Could be something recently fixed, as I'm using dmd git HEAD.
Comment #6 by hsteoh — 2014-09-23T05:18:14Z
Just tested with 2.064.2 (with -m64 -g), still can't reproduce this problem.
Comment #7 by hsteoh — 2014-09-23T05:19:04Z
Could you try with 2.067.0-b1 to see if it makes a difference?
Comment #8 by erikas.aubade — 2014-09-23T06:00:40Z
Hrm. 2.067-b1 has the same problem. So it might just be a system-local issue.
Comment #9 by hsteoh — 2014-09-23T14:29:20Z
That's very intriguing. I wonder what could be causing this problem? Unfortunately, I have no way to investigate it since I can't reproduce it. Somebody else would have to step up to look into it.
Comment #10 by robert.schadek — 2024-12-13T18:28:23Z