Breakpoints not cleared when stopping debug using J-Link GDB Server

[Uruloke]

Type: Debugger

Describe the bug

• OS and Version: Windows 10 1809
• VS Code Version: 1.31.1
• C/C++ Extension Version: 0.21.0
• Other extensions you installed (and if the issue persists after disabling them): None

Using gdb to debug a remote target using the J-Link GDB Server and stopping the debug session while the target is running causes an unclean shut down of the debug session. If a new debug session is then launched to the same J-Link GDB Server you are greeted with a message from the GDB server:

Debugger problem discovered:

The debugger has set two breakpoints at the same address 0xXXXXXXXX.

To Reproduce J-Link GDB Server requires a remote target to debug so unless you happen to have that reproducing it will prove difficult.

Steps to reproduce the behavior:

1. Start the J-Link GDB Server against a target
2. Start a debug session in VS Code
3. When it hits main() continue execution
4. Stop the debugging session
5. Start a new debug session in VS Code
6. Observe the above message dialog from J-Link GDB Server

Additional context The problem is in how the session is ended. Using engineLogging the following is observed:

1: (5663) <--exec-continue
1: (5666) ->^running
1: (5666) ->*running,thread-id="all"
1: (5666) ->(gdb)
1: (5666) ->&"\n"
1: (5666) ->^done
1: (5669) ->(gdb)
1: (8088) <--gdb-exit
1: (8093) ->^exit
1: (8093) ->&"Cannot execute this command while the target is running.\n"
1: (8093) ->&"Use the \"interrupt\" command to stop the target\n"
1: (8093) ->&"and then try again.\n"
1: (8093) ->=thread-group-exited,id="i1"
1: (8099) <-logout
1: (8099) "C:/arm/sysroot/bin/arm-none-eabi-gdb.exe" exited with code 0 (0x0).

The J-Link GDB Server does not allow you simply exit while the target is running hence no cleanup is performed. If you were to halt the target before stopping the session there are no issues at all.

[robotdad]

Interesting, so you don't reset the device between debug sessions?

[Uruloke]

The setup commands do actually. But it makes no difference. I've also tried to delete all breakpoints after launching the session a second time but that doesn't help either. When looking through the breakpoints using gdb I can't see any so I'm guessing it sets a breakpoint in a way that can't easily be viewed by the user. The breakpoint it complains about seems to always be the entry point for main().

I see I forgot to add my launch configuration. Here it is:

        {
            "name": "(JLink) Main Firmware",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/src/build-debug/firmware.elf",
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}/src/build-debug",
            "environment": [
                {
                    "name": "PATH",
                    "value": "C:\\arm\\sysroot\\bin"
                }
            ],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:/arm/sysroot/bin/arm-none-eabi-gdb.exe",
            "miDebuggerArgs": "--cd=\"${workspaceFolder}/src/build-debug\"",
            "preLaunchTask": "Debug",
            "targetArchitecture": "arm",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "text": "file firmware.elf"
                },
                {
                    "text": "target remote localhost:2331"
                },
                {
                    "text": "set mem inaccessible-by-default off"
                },
                {
                    "text": "monitor reset"
                },
                {
                    "text": "load"
                },
                {
                    "text": "monitor SWO EnableTarget 100000000 20000000 1 0"
                }
            ]
        }

[daantimmer]

I am facing the exact same issue, but then using Visual Studio 2017 in combination with a Segger j-link.

[cristianfunes79]

Hi all, having same issue here with ATSAMRH71 and JLinkGDBServer.

Could you fix it?

[Femtometer]

I've same issue in eclipse debug, it seems gdb default set breakpoint at main(). Devices like mine with low power mode, can't clear breakpoint until MCU power run out.

Solved: I change debug option, disable add breakpoint at main().

[mrx23dot]

I don't think it's possible to attach to running target without a reset. As said gdb doesn't stop at main by default, but the init script could contain 'b main', you can ask to remove all breakpoints, and issue another reset.