Thread overview
Dexed debugger UI now supports inspection of the variables based on mouse motion
Feb 13, 2020
Basile B.
Feb 13, 2020
Basile B.
Feb 14, 2020
Elronnd
Feb 15, 2020
Basile B.
Feb 17, 2020
Basile B.
February 13, 2020
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.
February 13, 2020
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
February 14, 2020
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?
February 15, 2020
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.
February 17, 2020
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.