Debugging generated files broken with C++ path-mapping

[keith]

Description of the bug:

Currently when using C++ path mapping for CppCompile actions, the final binary containing those path mapped files contains generated files at the path-mapped locations. These locations don't exist outside of the build action, so at runtime of the binary, if you attempt to fetch debug info, it will not work in today's common debugging workflows since the path is invalid.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

In this project, with a recent version of clang installed: repro.zip

First you can see the good behavior with:

bazel build :foo

You can check the binary already for the paths:

% llvm-dwarfdump bazel-bin/foo | grep generated.cpp
              DW_AT_name        ("bazel-out/k8-dbg/bin/generated.cpp")
                DW_AT_decl_file ("./bazel-out/k8-dbg/bin/generated.cpp")
                DW_AT_decl_file ("./bazel-out/k8-dbg/bin/generated.cpp")
                DW_AT_linkage_name      ("_GLOBAL__sub_I_generated.cpp")

And you can validate that path exists:

% cat ./bazel-out/k8-dbg/bin/generated.cpp
#include <iostream>

void foo() {
  std::cout << "from generated file" << std::endl;
}

If you want to validate this in the debugger you can run the binary and see that you correctly get source mapping:

% lldb bazel-bin/foo
(lldb) target create "bazel-bin/foo"
Current executable set to '/tmp/repro/bazel-bin/foo' (x86_64).
(lldb) b foo
Breakpoint 1: where = foo`foo() + 4 at generated.cpp:4:13, address = 0x00000000000019e4
(lldb) r
Process 10599 launched: '/tmp/repro/bazel-bin/foo' (x86_64)
Process 10599 stopped
* thread #1, name = 'foo', stop reason = breakpoint 1.1
    frame #0: 0x00005555555559e4 foo`foo() at generated.cpp:4:13
   1    #include <iostream>
   2
   3    void foo() {
-> 4      std::cout << "from generated file" << std::endl;
   5    }

Now to reproduce the path stripped / bad behavior:

bazel build :foo --config=strip

You can see the path embedded in the debug info does not exist:

% llvm dwarfdump bazel-bin/foo | grep generated.cpp
              DW_AT_name        ("bazel-out/cfg/bin/generated.cpp")
                DW_AT_decl_file ("./bazel-out/cfg/bin/generated.cpp")
                DW_AT_decl_file ("./bazel-out/cfg/bin/generated.cpp")
                DW_AT_linkage_name      ("_GLOBAL__sub_I_generated.cpp")
% cat ./bazel-out/cfg/bin/generated.cpp
cat: ./bazel-out/cfg/bin/generated.cpp: No such file or directory

And when you attempt to debug you won't get valid source maps:

% lldb bazel-bin/foo
(lldb) target create "bazel-bin/foo"
Current executable set to '/tmp/repro/bazel-bin/foo' (x86_64).
(lldb) b foo
Breakpoint 1: where = foo`foo() + 4 at generated.cpp:4:13, address = 0x00000000000019e4
(lldb) r
Process 11771 launched: '/tmp/repro/bazel-bin/foo' (x86_64)
Process 11771 stopped
* thread #1, name = 'foo', stop reason = breakpoint 1.1
    frame #0: 0x00005555555559e4 foo`foo() at generated.cpp:4:13

Which operating system are you running Bazel on?

linux x86_64

What is the output of bazel info release?

723872c

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[keith]

In lldb you can workaround this with source maps, so in this case:

settings set target.source-map bazel-out/cfg bazel-out/k8-dbg

Fixes it, but depending on the transitions the second value might change here

[keith]

I guess an ideal second value for most cases would instead be to map bazel-out/cfg/bin to bazel-bin, but i know that symlink gets removed sometimes, especially potentially in this case, because of multiple transitions in the build