Support disassembly view

[QuocDoBV]

When using multicore debugging using the CDT-amalgamator feature in the VS Code debug plugin. Disassembly view is not available for amalgamator debug launches. We need to support disassembly view for this case.

The eventual solution that was agreed on needed to workaround problems in VSCode:

1. VSCode assuming that the instructionPointerReference has the same format as DisassembledInstruction.address even though the spec doesn't say so. See the spec at https://microsoft.github.io/debug-adapter-protocol/specification#Types_StackFrame The problem has been reported at instructionPointerReference has the same format as DisassembledInstruction.address microsoft/vscode#164875
2. VSCode/debug adapter protocol does not support multiple memory spaces. The problem has been reported at VSCode does not support multiple memory spaces microsoft/vscode#164877

Solution:

• Based on elements: start addresses or end addresses or the instructionPointerReference to determine the child dap to be handled.

Notes:

1. This should be updated after problems are resolved
2. Limit of the solution is this can work incorrectly when child daps have same start addresses or end addresses or the instructionPointerReference.

[jonahgraham]

I think I understand what you are doing here. I assume the problem you are facing is there is no context in a disassembleRequest to identify which childDap to use? Your solution is reasonable, but has a limitation that it only works in this one use of the childDap creating the memory reference. What I propose below allows the IDE client to create new and arbitrary memory references. This will easily extend to memory reads and writes too.

We should define a bidirectional scheme that the amalgamator can use to map client requests to the correct child dap, and take memory references returned by a child dap and add something to them so they can be sent to the client.

e.g. memory references of child daps could require something like the name, index or ID as a prefix.

I would recommend that the memory reference be ChildDapArguments.index + ":" + addressReference within child dap.

The index field may need to be saved from the argument index in createChild

I have made comments on the individual lines on what the local code should be.

[QuocDoBV]

Dear @jonahgraham-san,
I have some updates after your review. As the issue related to VS code source, I have added a workaround for this. Could you please review it again? Currently, there is a big problem is that whenever we run program (step over, step in, step out....) with disassembly view opened, disassemble command is never called, So in this case disassembleRequest will not be called.

Here it the trace of that situation

[10:25:29.077 UTC] From client: next({"threadId":1000,"granularity":"instruction"})
[10:25:29.094 UTC] To client: {"seq":0,"type":"response","request_seq":130,"command":"next","success":true}
[10:25:29.279 UTC] To client: {"seq":0,"type":"event","event":"stopped","body":{"reason":"step","threadId":1000,"allThreadsStopped":false,"preserveFocusHint":false}}
[10:25:29.285 UTC] From client: threads(undefined)
[10:25:29.305 UTC] To client: {"seq":0,"type":"response","request_seq":131,"command":"threads","success":true,"body":{"threads":[{"id":1000,"name":"RL:  1 (single core)"},{"id":1001,"name":"LLVM:  1 (single core)"}]}}
[10:25:29.327 UTC] From client: stackTrace({"threadId":1000,"startFrame":0,"levels":20})
[10:25:29.349 UTC] To client: {"seq":0,"type":"response","request_seq":132,"command":"stackTrace","success":true,"body":{"stackFrames":[{"id":1033,"source":{"name":"SimulatorRL.c","path":"D:\\workspace\\Project_ARM_G4MH\\SIM\\SimulatorRL\\src\\SimulatorRL.c","sourceReference":0},"line":30,"column":0,"name":"main","instructionPointerReference":"0:0x00000249"}],"totalFrames":1}}
[10:25:29.376 UTC] From client: stackTrace({"threadId":1000,"startFrame":0,"levels":20})
[10:25:29.399 UTC] To client: {"seq":0,"type":"response","request_seq":133,"command":"stackTrace","success":true,"body":{"stackFrames":[{"id":1034,"source":{"name":"SimulatorRL.c","path":"D:\\workspace\\Project_ARM_G4MH\\SIM\\SimulatorRL\\src\\SimulatorRL.c","sourceReference":0},"line":30,"column":0,"name":"main","instructionPointerReference":"0:0x00000249"}],"totalFrames":1}}
[10:25:29.816 UTC] From client: scopes({"frameId":1033})
[10:25:29.821 UTC] To client: {"seq":0,"type":"response","request_seq":134,"command":"scopes","success":true,"body":{"scopes":[{"name":"Local","variablesReference":1046,"expensive":false},{"name":"Registers","variablesReference":1047,"expensive":true}]}}
[10:25:29.843 UTC] From client: variables({"variablesReference":1046})
[10:25:29.882 UTC] To client: {"seq":0,"type":"response","request_seq":135,"command":"variables","success":true,"body":{"variables":[{"name":"k","value":"0","type":"volatile int","memoryReference":"&(k)","variablesReference":0},{"name":"l","value":"0","type":"volatile int","memoryReference":"&(l)","variablesReference":0}]}}

[jonahgraham]

Currently, there is a big problem is that whenever we run program (step over, step in, step out....) with disassembly view opened, disassemble command is never called, So in this case disassembleRequest will not be called.

This sounds like a VSCode bug at first - but there may be something else going on as if I run cdt-gdb-adapter on its own I see subsequent disassemble requests happening. The trace you have provided looks like one of the children's traces. Do you have the trace of the amalgamator? The first thing I would look for is making sure all previous disassemble requests have a response, especially in light of the missing response in the else case below.

PS. I made two changes to this issue:

1. I marked all resolved conversations as resolved so it is easier to see what is left to discuss
2. I "hid" the trace in your last comment in a details.

[QuocDoBV]

Currently, there is a big problem is that whenever we run program (step over, step in, step out....) with disassembly view opened, disassemble command is never called, So in this case disassembleRequest will not be called.

This sounds like a VSCode bug at first - but there may be something else going on as if I run cdt-gdb-adapter on its own I see subsequent disassemble requests happening. The trace you have provided looks like one of the children's traces. Do you have the trace of the amalgamator? The first thing I would look for is making sure all previous disassemble requests have a response, especially in light of the missing response in the else case below.

PS. I made two changes to this issue:

1. I marked all resolved conversations as resolved so it is easier to see what is left to discuss
2. I "hid" the trace in your last comment in a details.

The trace that I provided to you is the trace of the amalgamator. I have configurated launch.json like below:
` "version": "0.2.0",
"configurations": [

  {
    "type": "amalgamator",
    "request": "launch",
    "name": "Debug Multiple",
    "logFile": "C:/VSCode/amalgamator.txt",
    "verbose": true,
    "debugServer": 4711,
    "children": [
      {
        "name": "RL",
        "debugAdapterRuntime": "node",
        "debugAdapterExecutable": "D:/1/3/renesas-gdb-vscode/node_modules/@renesas-e2s/renesas-gdb-adapter/dist/renesasDebugTargetAdapter.js",
        "arguments": {
          "type": "gdbtarget",
          "request": "launch",
          "gdbNonStop": "true",`

[jonahgraham]

The trace that I provided to you is the trace of the amalgamator.

Sorry, I misread it. I can see that it is indeed the amalgamator now. Sorry about the confusion.

Can you provide the whole trace? Is there a message with no response earlier for example?

[QuocDoBV]

The trace that I provided to you is the trace of the amalgamator.

Sorry, I misread it. I can see that it is indeed the amalgamator now. Sorry about the confusion.

Can you provide the whole trace? Is there a message with no response earlier for example?

Dear @jonahgraham
This is the whole trace
amalgamator.txt

[jonahgraham]

Thanks - that is strange. When I run cdt-gdb-adapter by itself i see the subsequent disassemble requests coming from vscode. If you run directly with cdt-gdb-adapter does it work properly?

Maybe there is something going bad with the way we annotate the instructionPointerReference. If you remove the annotation (1:) and hard code to always use dap 1 does that fix it?

It sounds like we may have to debug vscode itself to figure this one out.

[QuocDoBV]

Thanks - that is strange. When I run cdt-gdb-adapter by itself i see the subsequent disassemble requests coming from vscode. If you run directly with cdt-gdb-adapter does it work properly?

It works normally when I run with cdt-gdb-adapter

[QuocDoBV]

Maybe there is something going bad with the way we annotate the instructionPointerReference. If you remove the annotation (1:) and hard code to always use dap 1 does that fix it?

It also run normally when remove frame.instructionPointerReference = childIndex + ':' + frame.instructionPointerReference;

[jonahgraham]

It also run normally when remove frame.instructionPointerReference = childIndex + ':' + frame.instructionPointerReference;

Sounds like vscode is assuming something about the data in instructionPointerReference beyond what is in the spec. I will have a look at the code to see if it stands out to me, then you can file a bug report.

[jonahgraham]

There is indeed an issue in VSCode, this line which reads:

if (element && this._disassemblyView.currentInstructionAddresses.includes(element.instruction.address)) {

compares currentInstructionAddresses and address as strings and assumes that both will be in the same format. So our code does the 1: prefix which doesn't match that.

Two lines later the same same type of comparison error is made. So to me it looks like there are a number of assumptions in VSCode that don't match the DAP spec.

However, what the code is doing is treating DisassembledInstruction.address and instructionPointerReference as having the same format and in most place uses them interchangeably. However eventually it does parse the DisassembledInstruction.address as a number.

I think it would be great to fix vscode here so that it works with memory spaces. Did you ever file the earlier bugs on this issue we discussed in #7 (comment) ?

[QuocDoBV]

There is indeed an issue in VSCode, this line which reads:

if (element && this._disassemblyView.currentInstructionAddresses.includes(element.instruction.address)) {

compares currentInstructionAddresses and address as strings and assumes that both will be in the same format. So our code does the 1: prefix which doesn't match that.

Two lines later the same same type of comparison error is made. So to me it looks like there are a number of assumptions in VSCode that don't match the DAP spec.

However, what the code is doing is treating DisassembledInstruction.address and instructionPointerReference as having the same format and in most place uses them interchangeably. However eventually it does parse the DisassembledInstruction.address as a number.

I think it would be great to fix vscode here so that it works with memory spaces. Did you ever file the earlier bugs on this issue we discussed in #7 (comment) ?

-> I'm sorry I haven't done it yet. Since I don't really understand what the problem is here, I plan to report it after I really understand what the problem is.

[jonahgraham]

Hopefully with my #7 (comment) you can now understand the problem. Feel free to ask follow ups. The summaries of the bugs:

• VSCode assumes that instructionPointerReference has the same format as DisassembledInstruction.address even though spec does not say so
• VSCode/debug adapter protocol do not support multiple memory spaces, i.e. different children having different views of memory

[QuocDoBV]

Hopefully with my #7 (comment) you can now understand the problem. Feel free to ask follow ups. The summaries of the bugs:

• VSCode assumes that instructionPointerReference has the same format as DisassembledInstruction.address even though spec does not say so
• VSCode/debug adapter protocol do not support multiple memory spaces, i.e. different children having different views of memory

Thank you so much. I will file these bugs in next working day. So does that mean we will support disassembly view once these bugs are resolved?

[jonahgraham]

I think so, needs testing to see what else may be going on here. I don't know if it is in scope for Renesas to fund, but Renesas could simply provide a PR to VSCode that fixes these things.

[jonahgraham]

This looks quite reasonable to me, just needs some code simplification and an explanation somewhere as to "why" do it this way, and what the risk is, cross-referenced with the VSCode issue.

[jonahgraham]

Thank you for the comment @QuocDoBV - I am reproducing it in the OP for visibility.