GDB Breakpoints are set in all files with same name

[ZobyTwo]

When setting a breakpoint in a file with a particular name, breakpoints are set in all files with that file name at the same line.

Environment

Win 10
VSCode 1.15 stable build
C/C++ 0.12.2
No other extension installed.
Gdb 7.6.1 is from mingw32
Gcc 5.3.0 is from mingw32

Reproduce

Create the following project layout:

src
 |- main.c
 |- folder
    |- main.c

That is, there are two main.c files. One directly in src:

int foo();
int main(int argc, char *argv[])
{
    int a = 0;
    a += 3;
    a *= 4;

    foo();

    return 0;
}

The other in src/folder:

int foo()
{
    int b = 14;
    int d = 13;
    b += d - b * d;
    return b + d;
}

In both files, line 5 contains executable code.

Compile from within src:

gcc main.c folder/main.c -g -O0 -o a.exe

Add launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/src/a.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}

Set breakpoint in src/main.c at line 5. Launch debugger, it breaks in main, hit continue and it will break in foo (which it should not).

The above setup:

Breakpoints.zip

Settings

    "debug.allowBreakpointsEverywhere": true

c_cpp_properties.json is not in use and launch.json is given above.

[ZobyTwo]

@pieandcakes Could you please elaborate on why this is considered a request for a feature?

From my perspective, this looks like a bug, really. I have a project with a few hundred *.c files with the same name (they are mostly generated by another tool) and this makes it very hard to debug them because the debugger breaks at seemingly random places - additional to the line where I did set a breakpoint.

[pieandcakes]

@ZobyTwo When we send the bindings for the breakpoints we are currently only sending the filename. As such, it is "by design" even though it is unintended. There have been changes in MIEngine to allow support of this. I'll mark it as a bug also but either way it will require work on my part to get it to work.

[ZobyTwo]

@pieandcakes I see, thanks for the explanation.

[tobiaskohlbau]

I've the same bug/lack of feature as I use cpptools to debug an ARM Processor with multiple cores. As each core gets it's own main.cpp (entrypoint) vscode breaks on every line. Would be nice if this feature/bug could be implemented/resolved.

Is the bug has been resolved ?

[mpups]

Seems to still be a problem (at least in 8.1-0ubuntu3). I tried to get round this by setting the full path name of the file but GDB doesn't like this either. I guess it is not using realpath internally to disambiguate files.

[Ju57iCe]

Any ETA or roadmap on this? The breakpoint features seem frozen for so long - data breakpoints, log points.

[rsbondi]

When we send the bindings for the breakpoints we are currently only sending the filename

I have a possibly related issue based on the quote, the object file is built with prefix_filename so it is missing the breakpoint in filename.c(red, looks set but not hit), is this a symptom of the same issue? Is there a workaround?

[psclkhoury]

I am having the same issue but with the vs debugger and it's quite annoying.

We have a big repository and some files have the same name but in a different path.

When I put a breakpoint in Folder1/Folder2/Util.cpp, all the Util.cpp will break regardless of their paths. This makes the debugger unusable.

This is my launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Loader",
      "type": "cppvsdbg",
      "request": "launch",
      "program": "c:/SomeExecutable.exe",
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}",
      "externalConsole": true,
    }
  ]
}

[pieandcakes]

@psclkhoury It is on our list for current work planning.