I request variables for scope and get "this" in the list but it has variablesReference = 0. It means that the variable has no children. https://microsoft.github.io/debug-adapter-protocol/specification#Types_Variable 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 { public: void increment() { ++i; } private: int i = 0; }; Log: 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"})
Yes, pointers ought to have a single child.
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?
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").
I have a patch for this but it should probably wait for this series: https://sourceware.org/pipermail/gdb-patches/2023-August/201771.html 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.
https://sourceware.org/pipermail/gdb-patches/2023-September/202169.html
Can I somehow check the patch? As far as I understood it is not merged yet.
(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: https://github.com/tromey/gdb/commits/dap-30821-pointers
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a56e5dce69bfad45ee6977a916ccea283e087e8b 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
Fixed.
Thank you!