cc_toolchain not mounted to sandbox for preprocess_assemble action

[Nick Kirkby]

Hello,

I've encountered a discrepancy between the `preprocess_assemble` and `assemble` actions that I'm not sure how to resolve.

I'm using bazel to invoke arm-none-eabi-gcc on assembly codes provided by various vendors. Some use the ".S" suffix, others use ".s". I'm currently unable to assemble ".s" files because the toolchain isn't mounted into the sandbox. My hack is to rename "*.s" files to "*.S" after which everything works as expected.

Examining `CppFileTypes.java` in the bazel source, I see that ".s" is matched to the ASSEMBLER FileType and ".S" is matched to the ASSEMBLER_WITH_C_PREPROCESSOR FileType.

I have written a toolchain configuration that uses the newer `action_configs` API on `cc_common.create_toolchain_config_info(...)` like this:

        action_config(
            action_name = ACTION_NAMES.preprocess_assemble,
            tools = [
                struct(
                    type_name = "tool",
                    tool = ctx.file.gcc,
                )
            ]
        ),
        action_config(
            action_name = ACTION_NAMES.assemble,
            tools = [
                struct(
                    type_name = "tool",
                    tool = ctx.file.gcc,
                )
            ]
        ),

I've confirmed that these two action_configs are in fact used for ".S" and ".s" files by the following method:

For ".S" files:

1. remove the action_config corresponding to ACTION_NAMES.preprocess_assemble

2. observe that build fails with error:

    src/main/tools/linux-sandbox-pid1.cc:518 "execvp(toolchains/DUMMY_GCC_TOOL, 0x971510)":  No such file or directory

3. replace the action_config corresponding to ACTION_NAMES.preprocess_assemble

4. observe that the build succeeds

For ".s" files:

1. remove the action_config corresponding to ACTION_NAMES.assemble

2. observe that build fails with error:

    src/main/tools/linux-sandbox-pid1.cc:518 "execvp(toolchains/DUMMY_GCC_TOOL, 0x1a44180)":  No such file or directory

3. replace the action_config corresponding to ACTION_NAMES.assemble

4.  observe that build fails with error:

    src/main/tools/linux-sandbox-pid1.cc:518 "execvp(external/arm_none_eabi_linux_x86_64/bin/arm-none-eabi-gcc, 0xb2b180)":  No such file or directory

Using `--sandbox_debug` I observe that when successfully assembling ".S" files, `bazel_tools`, `local_config_cc` and my toolchain are present in the sandbox in addition to source files. When attempting to assemble ".s" files however, only the source files are present.

Does anyone know why the toolchain is mounted for the preprocess_assemble action but not the assemble action?

Kind regards,

Nick

 

[Nick Kirkby]

I've uploaded a full example here:

driftregion/bazel-action-preprocess-assemble-repro (github.com)

[David Turner]

As far as I understand, what appears in the sandbox of C++ related actions is controlled by the native.cc_toolchain() definition.
The action_config values themselves only control what flags are expanded in actions, not what goes in the corresponding sandbox.

In your case, you probably need to ensure that gcc is listed in the cc_toolchain() `as_files` attribute which is used for pure assembly operations. I assume that `compiler_files` is used instead for preprocess assembly, which would explain what you are seeing.

Hope this helps,

- Digit

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/58d97d0e-14cb-4b82-9cc4-46cc2741cd6bn%40googlegroups.com.

[Nick Kirkby]

Thank you Digit. You're exactly right. Passing gcc to `as_files` has solved this problem.