Bazel cc_toolchain for non-gnu TI DSP compiler - build

Question

I'm porting a TI C6000 DSP build from Makefile to Bazel. This DSP is running on a very complex embedded system, and we are already building the same code for multiple other processors using Bazel, but those other processors use GNU flavored (e.g. gcc-based) compilers.
The cc_rules package seems to make assumptions about the flags, filename extensions etc. I'm hoping I can avoid creating a completely custom toolchain, which would involve porting all the existing BUILD files to use different rules depending on the toolchain.
I can't seem to find any documentation on customizing those attributes, or others. The things that I already know I need to customize:
The flag that is used to specify the output file: -fr=filename and -fs=filename vs -o filename
Implicit dependency generation: someone told me that cc_rules generates .d files under the hood to detect whether you have missing dependencies. I'm not sure if this is true or not, but if so, I need to change the flag and extension used
The extension of the object and library files: as noted above, we build the same files for multiple CPUs, and need to customize the extension of the output for the rules.
There are probably other requirements that I'm not aware of yet as well. It very may well be that I'm doing it all wrong and should take a different approach. We have been using Bazel since the early days (v0.12), and still may have holdovers from then.
We are currently on v1.1.0, which I ported us to from v0.12 six months ago. I'm surprised that the master branch is already on v3.???!!!
Any help is greatly appreciated. Please remind me if I've left out anything important.
EDIT: One thing to note is that the compiler appears to be based on clang and llvm. If there are examples of clang/llvm-based toolchains (I'm pretty sure there are) then I could get started there.
I know that the enscriptem example in the docs is technically a LLVM-based compiler, but that uses a script to do magic to the params, etc. I can do that if that's the right thing to do, but I want to make sure I'm headed down the right path.

Answer 1

This is not a complete answer to all of your questions, but this also goes beyond what could be formatted and posted as comment. To your most recent inquiry. This snippet would redefine option used for output file (instead of -o OUTPUT to -fr=OUTPUT):
compiler_output_flags_feature = feature(
name = "compiler_output_flags",
flag_sets = [
flag_set(
actions = [
ACTION_NAMES.assemble,
ACTION_NAMES.c_compile,
ACTION_NAMES.cpp_compile,
ACTION_NAMES.cpp_header_parsing,
ACTION_NAMES.cpp_module_compile,
ACTION_NAMES.cpp_module_codegen,
],
flag_groups = [
flag_group(
flags = ["-fr=%{output_file}"],
),
],
),
],
)
As for available and used actions, you can check this out. For features, as you've already discovered: disabling legacy features and see what you need is one option. There is also this list in the docs that you've stumbled upon. Beyond that (incl. what variables are available at which point), it's a bit of "use the source, Luke" at least that's where I usually for better or worse ended heading for details. For action a good point would be here.
But I also find checking out other pre-packaged toolchain configs (esp. MSVC for being... different) insightful.

Answer 2

I think that adding your own custom rule that provides CcToolchainConfigInfo, would solve the problem you are having.
def _impl(ctx):
tool_paths = [
tool_path(name = "gcc", path = "/<abs>/<path>/clang"),
tool_path(name = "ld", path = "/<abs>/<path>/ld"),
tool_path(name = "ar", path = "/<abs>/<path>/ar"),
tool_path(name = "cop", path = "/bin/false"),
tool_path(name = "gcov", path = "/bin/false"),
tool_path(name = "nm", path = "/bin/false"),
tool_path(name = "objdump", path = "/bin/false"),
tool_path(name = "strip", path = "/bin/false"),
]
toolchain_compiler_flags = feature(
name = "compiler_flags",
enabled = True,
flag_sets = [
flag_set(
actions = [
ACTION_NAMES.assemble,
ACTION_NAMES.preprocess_assemble,
ACTION_NAMES.linkstamp_compile,
ACTION_NAMES.c_compile,
ACTION_NAMES.cpp_compile,
ACTION_NAMES.cpp_header_parsing,
ACTION_NAMES.cpp_module_compile,
ACTION_NAMES.cpp_module_codegen,
ACTION_NAMES.lto_backend,
ACTION_NAMES.clif_match,
],
flag_groups = [
flag_group(flags = ["<compiler-flags>"]),
],
),
],
)
toolchain_linker_flags = feature(
name = "linker_flags",
enabled = True,
flag_sets = [
flag_set(
actions = [
ACTION_NAMES.linkstamp_compile,
],
flag_groups = [
flag_group(flags = ["<linker-flags>"]),
],
),
],
)
return cc_common.create_cc_toolchain_config_info(
ctx = ctx,
toolchain_identifier = ctx.attr.toolchain_identifier,
host_system_name = ctx.attr.host_system_name,
target_system_name = "<your-system-name>",
target_cpu = "<your-cpu>",
target_libc = "<your-libc>",
compiler = "<your-compiler>,
abi_version = "<your-eabiu>",
abi_libc_version = <your-version>,
tool_paths = tool_paths,
features = [
toolchain_compiler_flags,
toolchain_linker_flags,
<more-custom-features>,
],
)
cc_arm_none_eabi_config = rule(
implementation = _impl,
attrs = {
"toolchain_identifier": attr.string(default = ""),
"host_system_name": attr.string(default = ""),
},
provides = [CcToolchainConfigInfo],
)
I have posted an example about using GCC embedded toolchains with Bazel on Github that you could use as a template. The example works with the arm-none-eabi-gcc compiler, but in principle, it would work just as well with clang.