[bazel] Define rules-based CC lowRISC toolchain

[jwnrt]

Summary

This PR defines a lowRISC toolchain configuration using the new rules added to rules_cc in version 0.0.10 and supersedes the rules from CRT. The actual toolchain and its flags should be identical.

This removes the final dependency that needed to be migrated to Bzlmod.

Overview

The RISC-V C/C++ compiler we're using (the lowRISC toolchain) is currently configured for Bazel in the CRT repo. The correct binaries and flags are bound together in such a way that Bazel can use them to compile, assemble, link, etc.

The rules in CRT are much easier to use than the old way of configuring toolchains in Bazel. The Pigweed project similarly implemented their own rules for configuring toolchains and got them upstreamed into the official rules_cc: https://pigweed.dev/docs/blog/06-better-cpp-toolchains.html

These new rules are very similar to the rules from CRT. This PR uses the new rules to configure the lowRISC toolchain within the OpenTitan repository.

Benefits

• CRT does not yet support Bzlmod and we had some difficulties porting it.
  • CRT is our last non-bzlmod dependency. This PR is the final step to fully supporting Bzlmod.
• Configuring the toolchain within the OpenTitan repo makes it easier to iterate on.
  • The toolchain can be updated in one place rather than in two stages across CRT and OpenTitan.
  • New flags can be added and tested immediately on OpenTitan code.

Drawbacks

The new rules-based toolchains have a slightly different CCToolchainInfo provider to the previous ones. Tools are now associated with actions rather than as files. Bazel seems to be moving in the direction of deprecating the files-based associations, so it's a good thing for us to migrate, however there is a chance that some things will not yet be supported.

What this means concretely is that you cannot access tools from the cc_toolchain object using parameters like ld_executable and ar_executable. We were using this feature in some of our rules, and some dependencies like rules_foreign_cc use it too.

Bazel now wants you to use cc_common.get_tool_for_action however this isn't a 1:1 replacement. You can only access tools associated with the CC actions Bazel uses (compiling, linking, etc). For some reason there's no action for objdump even though that tool can be part of the CC toolchain.

I have worked around this by accessing tools directly from the cc_toolchain's data files. This could be considered a hack, but I don't think there are any issues with doing this.

See bazelbuild/rules_cc#297

edit: see conversations below. We are now using get_tool_for_action for everything except the OTBN toolchain which actually needs specifically RISCV32 tools. That toolchain now loads binaries directly from the lowrisc toolchain repository which is more correct.

Testing

The toolchain should be configured the same as from CRT. I've checked that the mask ROM has the same hash when compiled before and after this PR:

# before
$ bazel build //sw/device/silicon_creator/rom:mask_rom --platforms=@crt//platforms/riscv32:opentitan
$ sha256sum bazel-bin/sw/device/silicon_creator/rom/mask_rom_silicon_creator.39.scr.vmem
dbab0d7bcee7d27b9ad17ba450ad98f250c8833c9d5868eed0f39da64dff01b1

# after
$ bazel build //sw/device/silicon_creator/rom:mask_rom --platforms=//third_party/lowrisc:opentitan_platform
$ sha256sum bazel-bin/sw/device/silicon_creator/rom/mask_rom_silicon_creator.39.scr.vmem
dbab0d7bcee7d27b9ad17ba450ad98f250c8833c9d5868eed0f39da64dff01b1

The flags that CRT adds are spread across these three files:

1. https://github.com/lowRISC/crt/blob/main/platforms/riscv32/features/BUILD.bazel
2. https://github.com/lowRISC/crt/blob/main/features/common/BUILD.bazel
3. https://github.com/lowRISC/crt/blob/main/features/embedded/BUILD.bazel

Compare to the flags added in this version:

• https://github.com/lowRISC/opentitan/pull/25810/files#diff-5eef6735ff2e1fb3a5c85350604c67514f801edf3a423cecdf01e41d8868f045

[jwnrt]

Ah, English Breakfast is broken because it doesn't use bitmanip and I took away the feature for enabling that.

[pamaury]

Regarding the problem with actions vs tools, would it make sense to define custom actions using cc_action_type to work around this?

[jwnrt]

There was a new feature added to CRT after I started this work: lowRISC/crt#41

I'll need to port those flags too

[jwnrt]

Regarding the problem with actions vs tools, would it make sense to define custom actions using cc_action_type to work around this?

Hmm, that looks like it could work actually. I'll take a look at this.

[jwnrt]

I tried out the action_type method and it mostly does seem to work, but honestly it ends up being more complicated and I think error prone than looking up tools directly. With the action types, you're still looking them up by string but now the string is something we define within the bazel project and it has to match everywhere it's used.

The built-in actions expose their names through @rules_cc//cc:action_names.bzl constants, but even those are unintuitive. The name for the archiver is CPP_LINK_STATIC_LIBRARY_ACTION_NAME for example.

For these situations in our repo where we know we want a specific tool like riscv32-unknown-elf-ld, I think it makes more sense to just ask for it directly.

[jwnrt]

I've also added the minsize feature and left it disabled by default since the version of CRT that it's added to hasn't been brought in here yet so it's not yet enabled.

[jwnrt]

@nbdd0121 @pamaury I have changed the code again to use cc_common.get_tool_for_action in the end like you both suggested.

The OTBN toolchain still needs specific riscv32-unknown-elf-* binaries and always will, so I've changed that code to depend directly on them from the lowrisc toolchain rather than pull them from the cc_toolchain.

In theory this will allow us to do things like introduce a CHERIoT toolchain as the cc_toolchain and have everything automatically load the right tools while OTBN can continue using its non-CHERIoT versions.

[pamaury]

Thanks @jwnrt Regarding OTBN, I think you new code is fine for now. Maybe we can revisit it later with either a custom toolchain or by adding custom actions for the missing tools if necessary.

[pamaury]

Looks good but I would suggest to use a constant for the objdump action.