www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - D globals in gdb

reply Martin Krejcirik <mk-junk i-line.cz> writes:
Hi all,

is there any way how to print a content of a D global variable in GDB ?
-- 
mk
Mar 31 2012
parent reply "Mihail Zenkov" <mihail.zenkov gmail.com> writes:
On Saturday, 31 March 2012 at 14:58:48 UTC, Martin Krejcirik 
wrote:

 Hi all,

 is there any way how to print a content of a D global variable 
 in GDB ?


Try in gdb:

p 'module_name.glob_var'

P.S. You can also use autocomplete: p 'module_name.<TAB><TAB>
Apr 02 2012
parent reply "Martin Krejcirik" <mk-junk i-line.cz> writes:
 Try in gdb:

 p 'module_name.glob_var'



argh, the single quotes. Thanks, now it works if the global is 
declared shared.
But if it isn't, print shows just the init value, no changed 
data. Any idea ?

--
mk
Apr 02 2012
parent reply simendsjo <simendsjo gmail.com> writes:
On Mon, 02 Apr 2012 19:36:27 +0200, Martin Krejcirik <mk-junk i-line.cz>  
wrote:


 Try in gdb:

 p 'module_name.glob_var'



 argh, the single quotes. Thanks, now it works if the global is declared  
 shared.
 But if it isn't, print shows just the init value, no changed data. Any  
 idea ?

 --
 mk


Unless it's shared or __gshared, every thread gets it's own copy. D  
defaults to thread local storage (TLS).
Apr 02 2012
parent reply Martin Krejcirik <mk-junk i-line.cz> writes:
On 2.4.2012 19:56, simendsjo wrote:

 Unless it's shared or __gshared, every thread gets it's own copy. D
 defaults to thread local storage (TLS).


I know but the problem is, that gdb doesn't show the changed value of
TLS variable. Example:

import std.stdio;

shared int shrgl = 1;
int tlsgl = 10;

void main()
{
   writefln("%s %s", shrgl, tlsgl); // prints 1,10
   shrgl++; tlsgl++;
   writefln("%s %s", shrgl, tlsgl); // prints 2,11
==> gdb p 'tls.shrgl' ==> 2
==> gdb p 'tls.tlslg' ==> 10
}

--
mk
Apr 02 2012
parent reply "Mihail Zenkov" <mihail.zenkov gmail.com> writes:
On Monday, 2 April 2012 at 22:24:36 UTC, Martin Krejcirik wrote:

 On 2.4.2012 19:56, simendsjo wrote:

 Unless it's shared or __gshared, every thread gets it's own 
 copy. D
 defaults to thread local storage (TLS).


 I know but the problem is, that gdb doesn't show the changed 
 value of
 TLS variable. Example:

 import std.stdio;

 shared int shrgl = 1;
 int tlsgl = 10;

 void main()
 {
    writefln("%s %s", shrgl, tlsgl); // prints 1,10
    shrgl++; tlsgl++;
    writefln("%s %s", shrgl, tlsgl); // prints 2,11
 ==> gdb p 'tls.shrgl' ==> 2
 ==> gdb p 'tls.tlslg' ==> 10
 }

 --
 mk


Can't reproduce. With gdc and dmd-2.058 I have correct result. 
GDB-7.3
Apr 02 2012
parent reply simendsjo <simendsjo gmail.com> writes:
On Tue, 03 Apr 2012 07:47:40 +0200, Mihail Zenkov  
<mihail.zenkov gmail.com> wrote:


 On Monday, 2 April 2012 at 22:24:36 UTC, Martin Krejcirik wrote:

 On 2.4.2012 19:56, simendsjo wrote:

 Unless it's shared or __gshared, every thread gets it's own copy. D
 defaults to thread local storage (TLS).


 I know but the problem is, that gdb doesn't show the changed value of
 TLS variable. Example:

 import std.stdio;

 shared int shrgl = 1;
 int tlsgl = 10;

 void main()
 {
    writefln("%s %s", shrgl, tlsgl); // prints 1,10
    shrgl++; tlsgl++;
    writefln("%s %s", shrgl, tlsgl); // prints 2,11
 ==> gdb p 'tls.shrgl' ==> 2
 ==> gdb p 'tls.tlslg' ==> 10
 }

 --
 mk


 Can't reproduce. With gdc and dmd-2.058 I have correct result. GDB-7.3


I cannot reproduce this on dmd-2.059 trunk either.
Apr 03 2012
parent reply Martin Krejcirik <mk-junk i-line.cz> writes:
On 3.4.2012 9:40, simendsjo wrote:

 Can't reproduce. With gdc and dmd-2.058 I have correct result. GDB-7.3


 I cannot reproduce this on dmd-2.059 trunk either.


Interesting. I'm using dmd 2.058 binary (.zip) on debian squeeze 32bit,
gdb-minimal 7.3-1~bpo60+1 from backports. Even tried to compile gdb 7.4,
but still the same behavior.

-- 
mk
Apr 03 2012
parent reply "Mihail Zenkov" <mihail.zenkov gmail.com> writes:
On Wednesday, 4 April 2012 at 01:23:34 UTC, Martin Krejcirik 
wrote:

 On 3.4.2012 9:40, simendsjo wrote:

 Can't reproduce. With gdc and dmd-2.058 I have correct 
 result. GDB-7.3


 I cannot reproduce this on dmd-2.059 trunk either.


 Interesting. I'm using dmd 2.058 binary (.zip) on debian 
 squeeze 32bit,
 gdb-minimal 7.3-1~bpo60+1 from backports. Even tried to compile 
 gdb 7.4,
 but still the same behavior.


I also use dmd-2.058/linux/bin32/dmd.
1. Try compile without options, just 'dmd tls.d'
2. How you set break point in the end of program? Try add this 
hack:
int *p = null;
*p = 5;
It segfault you program and you can check  backtrace and variable 
state.
Apr 04 2012
parent reply "Martin Krejcirik" <mk-junk i-line.cz> writes:
On Wednesday, 4 April 2012 at 07:01:39 UTC, Mihail Zenkov wrote:

 1. Try compile without options, just 'dmd tls.d'


I'm not sure what that should accomplish, as I wouldn't get the 
debug info.


 2. How you set break point in the end of program? Try add this


breakpoints are ok. In fact everything is ok, except it looks 
like that gdb is accessing (in print, set var) a "shadow" non-tls 
copy of my tls variable.

Consider this example:
import std.stdio;

__gshared int shrvar = 1;
int tlsvar = 5;

void main()
{
    writefln("%d %d | %#x %#x", shrvar, tlsvar, &shrvar, &tlsvar); 
// 1, 5
    shrvar++; tlsvar++;
    writefln("%d %d | %#x %#x", shrvar, tlsvar, &shrvar, &tlsvar); 
// gdb p 'tls.tlsvar' = 5
}

Now running GDB:

(gdb) b 10
Breakpoint 1 at 0x806b7ba: file tls.d, line 10.
(gdb) r
Starting program: /home/mk/dmd/tls
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/i686/cmov/libthread_db.so.1".
1 5 | 0x808f308 0xf7e466c8

Breakpoint 1, D main () at tls.d:10
10         writefln("%d %d | %#x %#x", shrvar, tlsvar, &shrvar, 
&tlsvar); // gdb p 'tls.tlslg' = 5
(gdb) n
2 6 | 0x808f308 0xf7e466c8
11      }
(gdb) info address tls.shrvar
Symbol "tls.shrvar()" is static storage at address 0x808f308.
(gdb) info address tls.tlsvar
Symbol "tls.tlsvar()" is static storage at address 0x808f004.
(gdb) x 0xf7e466c8
0xf7e466c8:     0x00000006
(gdb) x 0x808f004
0x808f004:      0x00000005

As you can see, the address of tlsvar in gdb is different then 
the one from writeln.

Trying similar C program in gdb, it correctly recognize the TLS 
variable:
(gdb) info address shrvar
Symbol "shrvar" is static storage at address 0x8049658.
(gdb) info address tlsvar
Symbol "tlsvar" is a thread-local variable at offset 0x0 in the 
thread-local storage for `/home/mk/dmd/glob'.

I read somwhere that it is necessary to link libpthread, not sure 
if that applies to DMD too, but it doesn't seem to have any 
effect anyway.
Apr 04 2012
parent reply "Mihail Zenkov" <mihail.zenkov gmail.com> writes:
On Wednesday, 4 April 2012 at 10:45:00 UTC, Martin Krejcirik 
wrote:

 On Wednesday, 4 April 2012 at 07:01:39 UTC, Mihail Zenkov wrote:

 1. Try compile without options, just 'dmd tls.d'


 I'm not sure what that should accomplish, as I wouldn't get the 
 debug info.


DMD without any flags produce enough debug info to see global 
variable.
I reproduce this problem: only dmd with flag -g have it. Without 
this flag or with -gc gdb show correct value.
Apr 04 2012
parent "Martin Krejcirik" <mk-junk i-line.cz> writes:
 DMD without any flags produce enough debug info to see global 
 variable.
 I reproduce this problem: only dmd with flag -g have it. 
 Without this flag or with -gc gdb show correct value.


Thanks, -gc works indeed.
Apr 04 2012