Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to view some addresses in disassembly. Reopening disassembly makes more addresses viewable, but doesn't remove the error #1006

Open
DanielLiebler opened this issue Apr 18, 2024 · 0 comments

Comments

@DanielLiebler
Copy link

Describe the bug
The disassembly window has very weird behavior. When scrolling up, an error occurs about not being able to load the region.
When closing and reopening and moving the disassembly window to another VSCode grid-pane, this region behaves fine, but the next memory region above that one creates an error of the same kind.

This is one of the errors:

Unable to disassemble: Error: Could not find an instruction at the baseAddress. Something is not right. Please report this problem:
{
  "command":"disassemble",
  "arguments":
    {
      "memoryReference":"0x080030c0",
      "offset":0,
      "instructionOffset":-300,
      "instructionCount":50,
      "resolveSymbols":true
    },
  "type":"request",
  "seq":22
}

The disassembly seems to be correct, after it could be loaded, so it seems to be related to some sort of check preventing the disassembly to be sent to the VSCode frontend. But this is only a guess, I dont really know enough about how this works under the hood.
Since the error is created at src/backend/disasm.ts:732 I would assume that the list of all instructions all.instructions somehow does not contain the correct list of instructions or is missing some instructions.

To Reproduce
Steps to reproduce the behavior:

  1. Start debug session
  2. Open the disassembly view
  3. Move the disassembly view to another VSCode grid-pane (eg. to view side-by-side or on another VSCode window monitor)
  4. Scroll up in the disassembly view
  5. See issue (eg. at instructionOffset -250)
  6. Close the disassembly view
  7. Open the disassembly view
  8. Move the disassembly view to another VSCode grid-pane (eg. to view side-by-side or on another VSCode window monitor)
  9. Scroll up in the disassembly view
  10. See issue again (eg. now at instructionOffset -300)

Note:
For some reason, I need to move the disassembly view to another grid-pane to have it load new lines past the ones queried in the initial query. If I dont move the disassembly view, I can only view the initial 400 instructions(-200 to +200). This is probably another bug worth looking into, but for the time being i can ignore it. I can still file another issue after we resolved this one.

Expected behavior

Expected would be to just scroll up and get the correct disassembly loaded on demand, without error. After getting the error for a section of 50 instructions, this error is not reappearing until the debug session is exited.

But reloading the disassembly view for every 50 assembly instructions is too tedious to be useful.

Screenshots

image

Environment (please complete the following information):

[comment]: <> Whenever possible, please make sure you are using the latest versions of VSCode and our extension

  • Cortex-Debug Version (this extension) [v1.12.1]
  • OS: [Windows 10]
  • EBlink version 5.12-[178] by Gerard Zagema [a modified GDB as far as i know]
  • Compiler Toolchain Version: [gcc-arm-none-eabi-10.3-2021.10]

Please include launch.json

Note: We are unlikely to look at the issue if you do not supply this

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug (ebLink)",
            "cwd": "${workspaceFolder}",
            "executable": "${command:cmake.buildDirectory}/${command:cmake.buildTargetName}.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "external",
            "gdbTarget": "localhost:2331",
            "svdFile": "${workspaceFolder}/build/target.svd",
            "showDevDebugOutput": "vscode",//"none",
            "breakAfterReset": true,
            "overrideLaunchCommands": [
                "monitor reset halt",
                "load",
                "monitor reset halt",
            ],
            "overrideResetCommands": [
                "set $sp=*(0x08000000)",
                "set $pc=*(0x08000004)",
                "monitor reset halt"
            ],
            "preLaunchTask": "start_eblink",
            "postResetCommands": [
            ],
        },
    ]
}

start_eblink task from tasks.json

        {
            "label": "start_eblink",
            "type": "shell",
            "command": "C:/Program Files (x86)/EBlink/win32/eblink.exe",
            "args": [
                "-I",
                "stlink",
                "-S",
                "auto",
                "-P",
                "C:/Program Files (x86)/EBlink/scripts",
                "-G",
                "s,nc"
            ],
            "isBackground": true,
            "dependsOn": "build CMake",
            "problemMatcher": {
                "owner": "EBlink",
                "fileLocation": "relative",
                "pattern": {
                    "regexp": "GDB Error: [\\s\\S]+",
                    "message": 1,
                    "file": 0,
                    "location": 0,
                    "kind": "file"
                },
                "background": {
                    "activeOnStart": true,
                    "beginsPattern": ".",//"^EBlink version \\d+\\.\\d+-\\[\\d+\\] by Gerard Zagema*",
                    "endsPattern": ".",//"^GDB listening \\(0\\.0\\.0\\.0 @ 2331\\)*",
                }
            }
        }

Attach text from Debug Console

I think vscode is the better debug level here. If not, tell me, I can also supply it with level raw.
log_disassembly.txt

Additional context
Only occurs when scrolling up, scrolling down is fine, even data sections become viewable.

Also, the disassembly seems fine once it is correctly loaded, and since its linked to closing and reopening the window, i think it rather stems from this extension. I really, really doubt my custom configuration with EBLink is creating those issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant