Thread overview
Dexed debugger UI now supports inspection of the variables based on mouse motion
5 days ago
Basile B.
5 days ago
Basile B.
4 days ago
Elronnd
3 days ago
Basile B.
1 day ago
Basile B.
5 days ago
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.
5 days ago
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
4 days ago
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?
3 days ago
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.
1 day ago
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.