Debugging not working anymore/GDB not starting since pre-release version 1.3.2

[Rehcsif]

Hi,
I have an issue since Pre-Release Version 1.3.2, the last version, which worked for me was 1.3.1.

How am I using Cortex-debug?

• using VSCode in Windows with WSL2 Terminal window
• compiling in WSL2 terminal window with GNU Toolchain (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads)
• debugging from VSCode in Windows with same toolchain under Windows
• launch.json:

        {
            "name": "Debug ...",
            "cwd": "${workspaceRoot}/Src",
            "executable": "../build/wrapped.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "hardwareBreakpoints": { "require": true },
            "sourceFileMap": { "/mnt/c": "c:\\" },
            "device": "STM32F427VI",
            "interface": "swd",
            "serialNumber": "",
            "runToEntryPoint": "main",
            "showDevDebugOutput": "both",
            "preLaunchCommands": [
                "add-symbol-file ../build/inner.elf 0x80701B0",
            ]          
        },

• I am debugging a "wrapped" firmware, where a bootloader + application is included
• I am using the GDB-command "add-symbol-file" to be able to set breakpoints etc. in the application
• I am using a J-Link PLUS Debug Probe

Maybe this is not the proper way of using Cortex-Debug? However this worked fine so far. I tried different pre-release versions. Up to version 1.3.1 it worked fine, starting with version 1.3.2 I cannot debug anymore. I've also tried to compile & debug directly with windows-toolchain, but this does also not work anymore.

All i get in the debug console, even with "showDevDebugOutput": "both" is:

Launching GDB: "C:\\my\\path\\gcc-arm-none-eabi-8-2019-q3-update-win32\\bin\\arm-none-eabi-gdb.exe" -q --interpreter=mi2 "C:\\Work\\embedded\\my\\path\\build\\wrapped.elf"
1-gdb-set target-async on
Reading symbols from arm-none-eabi-objdump.exe --syms -C -h -w C:\Work\embedded\my\path\build\wrapped.elf
Reading symbols from arm-none-eabi-nm.exe --defined-only -S -l -C -p C:\Work\embedded\my\path\build\wrapped.elf

Afterwards nothing happens. VSCode Debug Bar (where i can halt etc.) disappears.
Has this something to do with the changes in the startup-process mentioned in the changelog of V1.3.2? (objdump and nm).

Thank's in advance for any hints!

[haneefdm]

Hmmm. Are you able to manually run that same command?

arm-none-eabi-nm.exe --defined-only -S -l -C -p C:\Work\embedded\my\path\build\wrapped.elf > nm.txt

Wonder how large the output is. Even if nm crashes, we can still continue with debug. If the debug control bar disappeared, then the debugger backend (the program that talks to gdb) itself crashed.

[haneefdm]

Ohh, and this command too

arm-none-eabi-objdump.exe --syms -C -h -w C:\Work\embedded\my\path\build\wrapped.elf > objdump.txt

[haneefdm]

Would it be possible for you to try the most recent as of now is 1.3.4 pre-release. I don't think we changed anything that should affect how you are using this with WSL.

Both nm and objdump can crash and burn but you should still be able to debug (minus a few features).

What did change was how we added some code in case if the server or gdb crashes or disconnects unexpectedly. In what you reported above, it appears that gdb didn't even start or we crashed even before gdb started

[Rehcsif]

.txt file generated by nm is 174 KB and 639 lines
for objdump it are 77 KB and 736 lines

I just wanted to mention that running the command as you wrote it and like it is printed in the debug console does not work for me, as the toolchain .\bin folder is not in my path variable. Instead i inserted the full-path to the corresponding exe's like i specified in cortex-debug.gdbPath

Would it be possible for you to try the most recent as of now is 1.3.4 pre-release.

Yes I've done that, I tried multiple pre-release version from the version-history in VS-Code Marketplace. All I could see is that it worked up to Pre-Release Version 1.3.1. Starting with Pre-Release version 1.3.2 (so also 1.3.3, 1.3.4) it does not work any longer.

... it appears that gdb didn't even start or we crashed even before gdb started

Yep, that's what I also thought/guessed

[haneefdm]

Wild guess. Could you also set objdumpPath like you are setting gdbPath? That may be the issue. This has degenerated into 10 ways of setting paths for gdb/arm-tool-chain/etc.

[haneefdm]

I think I am able to duplicate the problem. An invalid objdump path causes a double fault. Was only handling a single fault.

[Rehcsif]

I just tried and setting objdumpPath solved the issue. Thanks!
By the way I switched from gdbPath and objdumpPath directly to armToolchainPath and it works too.

Maybe the log message in the debugconsole could state that path not found for nm and objdump if possible, then the user get's some hint where he needs to search/what he needs to fix

[haneefdm]

It died while printing an error :-) The two programs were running simultaneously and both errors (exceptions) happened.

I just fixed it. Should be in the next pre-release shortly.

[Rehcsif]

Oh perfect, thanks alot for your work!

[haneefdm]

Could you try out a manual build I created for both of your issues. I could not duplicate the RTT issue #599, however. Want to know if this is still an issue.

https://github.com/Marus/cortex-debug/releases/tag/v1.3.5-pre1

[Rehcsif]

Tried your manual build, for me it works fine. When armToolchainPath is set objdump + nm can be found.
I've also tested what happens if only the gdbPath is set and no path for nm and objdump is given. In this case the plugin now prints an error message as expected, showing that something is wrong with nm and/or objdump.

Error: arm-none-eabi-nm.exe failed! statics/global/functions may not be properly classified: Error: spawn arm-none-eabi-nm.exe ENOENT
 Expecting nm next to objdump. If that is not the problem please report this.
Error: objdump failed! statics/globals/functions may not be properly classified: Error: spawn arm-none-eabi-objdump.exe ENOENT Please report this problem.