Bug 30821 - DAP GDB: "this" have no children. It comes with "variablesReference" 0.
Summary: DAP GDB: "this" have no children. It comes with "variablesReference" 0.
Alias: None
Product: gdb
Classification: Unclassified
Component: dap (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 14.1
Assignee: Tom Tromey
Depends on:
Reported: 2023-09-04 08:34 UTC by Artem Sokolovskii
Modified: 2023-09-20 09:25 UTC (History)
1 user (show)

See Also:
Last reconfirmed: 2023-09-04 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Artem Sokolovskii 2023-09-04 08:34:37 UTC
I request variables for scope and get "this" in the list but it has variablesReference = 0. It means that the variable has no children.
I have a simple class and I should see "i" variable as a child of "this". At least I see it like this in not DAP GDB version.

class myClass
   void increment()

   int i = 0;

qtc.dbg.dapengine: dap response QJsonObject({"body":{"variables":[{"name":"this","value":"0x7fffffffda40","variablesReference":0},{"name":"i","value":"0","variablesReference":0}]},"command":"variables","request_seq":29,"seq":208,"success":true,"type":"response"})
Comment 1 Tom Tromey 2023-09-04 17:58:26 UTC
Yes, pointers ought to have a single child.
Comment 2 Tom Tromey 2023-09-05 13:11:57 UTC
I'm not really sure how references ought to behave.
My current patch treats them identically to pointers,
where a reference has a single child, which is the value.
But maybe they should just be completely invisible?
Comment 3 Artem Sokolovskii 2023-09-05 13:53:05 UTC
I don't fully understand your question. From my side, I just should get a tree kind of thing.

I sent you the wrong response in the bug sorry. I'm getting this:
qtc.dbg.dapengine: "Content-Length: 186\r\n\r\n{\"request_seq\": 36, \"type\": \"response\", \"command\": \"variables\", \"body\": {\"variables\": [{\"variablesReference\": 0, \"name\": \"this\", \"value\": \"0x7fffffffdab8\"}]}, \"success\": true, \"seq\": 87}"

So I'm getting "this" and the variablesReference is 0. So it means that it has no children. But it has "i". So I should get "this" with variablesReference e.g 1. And then I could request variables for this variablesReference like this:
"Content-Length: 86\r\n\r\n{\"arguments\":{\"variablesReference\":1},\"command\":\"variables\",\"seq\":50,\"type\":\"request\"}"
And should get a list with "i" inside.

So for gdb without DAP it sends it this way("i" is a child of "this").
Comment 4 Tom Tromey 2023-09-05 15:18:30 UTC
I have a patch for this but it should probably wait for this series:


My current patch regresses gdb.dap/scopes.exp, because it expects
the 'char *' variable not to have structure.
I'm not totally sure if the above series handles that well, but
it seems like it would be necessary infrastructure for it at least.

Hmm, it's been 2 weeks, perhaps I'll put that in.
Comment 6 Artem Sokolovskii 2023-09-06 08:52:19 UTC
Can I somehow check the patch? As far as I understood it is not merged yet.
Comment 7 Tom Tromey 2023-09-07 14:46:58 UTC
(In reply to Artem Sokolovskii from comment #6)
> Can I somehow check the patch? As far as I understood it is not merged yet.

You can download it from the mailing list (I use "b4" for this kind
of thing) or get it from my github:
Comment 8 Sourceware Commits 2023-09-19 19:34:35 UTC
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:


commit a56e5dce69bfad45ee6977a916ccea283e087e8b
Author: Tom Tromey <tromey@adacore.com>
Date:   Tue Sep 5 09:13:14 2023 -0600

    Handle pointers and references correctly in DAP
    A user pointed out that the current DAP variable code does not let the
    client deference a pointer.  Oops!
    Fixing this oversight is simple enough -- adding a new no-op
    pretty-printer for pointers and references is quite simple.
    However, doing this naive caused a regession in scopes.exp, which
    expected there to be no children of a 'const char *' variable.  This
    problem was fixed by the preceding patches in the series, which ensure
    that a C type of this kind is recognized as a string.
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30821
Comment 9 Tom Tromey 2023-09-19 19:34:55 UTC
Comment 10 Artem Sokolovskii 2023-09-20 09:25:20 UTC
Thank you!