www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Dexed debugger UI now supports inspection of the variables based on

reply Basile B. <b2.temp gmx.com> writes:
I don't know why I havent implemented this earlier as it was 
quite simple. It's basically the same as when you evaluate a 
custom expression excepted that you use the mouse position to 
extract a (more or less, TBH) precise unary expression.

     https://imgur.com/a/e4urRY9

Only problem is that GDB requires explicit dereferences, that are 
normally automatic in D semantic, so big chain of identifiers 
wont work and display '???'.

Example:

     for D       :    a.d.c.somevar
     GDB needs   :  (*a).(*d).(*c).somevar

if a,d and c are classes or struct pointers. So far dexed will 
display

______________________________________
exp: a.d.c.somevar
---
(result of -data-evaluate $exp)
---
(result of -data-evaluate *$exp)
______________________________________

so only one dereference. And in the a.d.c.somevar example this 
would not work.
Feb 13
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 13 February 2020 at 09:06:26 UTC, Basile B. wrote:
 I don't know why I havent implemented this earlier as it was 
 quite simple. It's basically the same as when you evaluate a 
 custom expression excepted that you use the mouse position to 
 extract a (more or less, TBH) precise unary expression.

     https://imgur.com/a/e4urRY9

 Only problem is that GDB requires explicit dereferences, that 
 are normally automatic in D semantic, so big chain of 
 identifiers wont work and display '???'.

 Example:

     for D       :    a.d.c.somevar
     GDB needs   :  (*a).(*d).(*c).somevar

 if a,d and c are classes or struct pointers. So far dexed will 
 display

 ______________________________________
 exp: a.d.c.somevar
 ---
 (result of -data-evaluate $exp)
 ---
 (result of -data-evaluate *$exp)
 ______________________________________

 so only one dereference. And in the a.d.c.somevar example this 
 would not work.
related commit https://gitlab.com/basile.b/dexed/-/commit/7a049959214db2e8818131b6943724e2b3a15ee5
Feb 13
prev sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Thursday, 13 February 2020 at 09:06:26 UTC, Basile B. wrote:
 GDB requires explicit dereferences, that are normally automatic 
 in D semantic, so big chain of identifiers wont work and 
 display '???'.

 Example:

     for D       :    a.d.c.somevar
     GDB needs   :  (*a).(*d).(*c).somevar
Can you say a->d->c->somevar instead?
Feb 14
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 14 February 2020 at 16:29:26 UTC, Elronnd wrote:
 On Thursday, 13 February 2020 at 09:06:26 UTC, Basile B. wrote:
 GDB requires explicit dereferences, that are normally 
 automatic in D semantic, so big chain of identifiers wont work 
 and display '???'.

 Example:

     for D       :    a.d.c.somevar
     GDB needs   :  (*a).(*d).(*c).somevar
Can you say a->d->c->somevar instead?
That does not work for me (GDB 8.3.5). I remember that there's a problem with D classes in GDB [1] (they have the same internal type as structs). This makes rewriting the expressions difficult without D semantic. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22480 Ideally using ptype it would be possible to accurately fix the expression copied from the source.
Feb 14
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 14 February 2020 at 16:29:26 UTC, Elronnd wrote:
 On Thursday, 13 February 2020 at 09:06:26 UTC, Basile B. wrote:
 GDB requires explicit dereferences, that are normally 
 automatic in D semantic, so big chain of identifiers wont work 
 and display '???'.

 Example:

     for D       :    a.d.c.somevar
     GDB needs   :  (*a).(*d).(*c).somevar
Can you say a->d->c->somevar instead?
Actually I'm a cunt... if the GDB answers were so bad it's because I used DMD. I definitively knew that its codegen is bad but I didn't know that the debug info too since I just read that... A test with the DWARF infos generated from LDC2 and a chain of 3 classes gives excellent results.
Feb 16