CppArchive path-mapping generated files issue

[keith]

Description of the bug:

Currently if you enable path-mapping for CppArchive, the archive points to generated files at a path that isn't valid outside of the path mapped action. Ideally there would be a way to make this work for common C++ debugging workflows

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.

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

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]

@fmeum do you have more specifics around this one?

[nikhilkalige]

I have been thinking about how to fix this. I have disabled path mapping for this reason. I was hoping to experiment with subrules to write a custom binary rewriter that modifies the dwarf data.

I don't even know whether subrules could support such a thing.

[keith]

I don't think i fully understand the issue. also does this matter at all if you're using --start-lib/--end-lib? since in that case you're not actually executing the archive actions

[fmeum]

Is this relevant for CppArchive? I would have expected this to be more of an issue with CppCompile in the case of generated source files.

We could maintain a symlink tree under bazel-out/cfg/bin with each symlink pointing to the unmapped path. This requires new logic in Bazel as well as a strategy for dealing with conflicts.

An alternative could be a rewriter that runs in a follow-up action. That logic has precedent in JavaCompileAction, but can't be implemented in Starlark yet without flattening depsets.

[keith]

I think I misunderstood your original message about that. It does seem like no CppArchive is required to have this issue. A single cc_binary with a generated source file is enough to cause it

[keith]

moving the debugging of generated files issue here #25382