bazel: build and test bare-metal examples#3220
Conversation
mgeisler
force-pushed
the
bazel-bare-metal
branch
4 times, most recently
from
ec71ec2 to
5f19e2c
Compare
djmitche
left a comment
djmitche
left a comment
There was a problem hiding this comment.
I admit I'm not quite sure why all of this is happening!
| 3. We wrap each binary target in a platform transition | ||
| (`aarch64_binary`) so they are built for the AArch64 bare-metal | ||
| target platform during host-executed tests. | ||
| """ |
There was a problem hiding this comment.
This file is quite repetitive -- could it be improved with a rule or a macro?
Hey @djmitche, yeah, fair point! #1168 is in some sense the starting point — it has bothered me for years that
At Proton, I've been part of introducing Bazel for our monorepo: building Rust, Kotlin, Swift, Typescript with it... So I naturally started looking deeper into it and realized that it's not so complicated. I kind of knew this from Google where we also use Bazel (Blaze) with What you, @qwandor and @gribozavr haven't seen yet is the Bazel build rules that actually do something interesting: namely configure Bazel "repositories" (those things that start with With that logic neatly wrapped in a repository rule in Bazel, it becomes easy to do (typed from memory): mdbook(
name = "da_html",
srcs = "@backdated_sources//:da_content",
book = "@backdated_sources//:da_book",
)and this gives you a I have this on my laptop which is not infront of me right now. But that is the end goal: generate per-language repositories which in turn are used to generate HTML, PDF, exerciser, ... outputs. Now, I must admit that the step towards that have been more bumpy that I expected! The LLVM toolchain sage (resolved for now in #3221) made things strangely unstable, unlike what I've seen on my own laptop. So I was expecting 
but it has been a little more than 20 minutes by now 😄 I will try and put up the other bits and pieces next so you and the rest of the admins can look at the whole thing together. |
| edition = "2024", | ||
| rustc_flags = [ | ||
| "-C", | ||
| "linker=rust-lld", |
There was a problem hiding this comment.
We don't have this flag in the Cargo.toml, why is it needed here?
| linker_script = ":image.ld", | ||
| rustc_flags = [ | ||
| "-C", | ||
| "linker=rust-lld", |
There was a problem hiding this comment.
Again, why does this need to be specified here?
| rust_binary( | ||
| name = "improved", | ||
| srcs = glob(["src/**/*.rs"]), | ||
| compile_data = glob(["src/**/*.S"]), |
There was a problem hiding this comment.
What's the difference between srcs and compile_data?
| fi | ||
|
|
||
| echo "Running ${BIN_NAME}.bin under QEMU..." | ||
| if [ -n "$NON_INTERACTIVE" ]; then |
There was a problem hiding this comment.
If the point of this script is to test the binaries, why does it need to be different in interactive shells? If they intention is to use it to run examples interactive then I think the script should be called run_example.sh rather than run_test.sh, and maybe take a flag rather than detecting whether it is interactive. Though I'm still not really keen on the parallel build systems, who is going to actually use this?
| """Bazel BUILD file for ARM Cortex-M Microcontroller Examples. | ||
|
|
||
| This package defines board support and hardware abstraction layer | ||
| (HAL) binaries for microcontrollers. Because this code targets ARM |
There was a problem hiding this comment.
Nit: this description is misleading, the binaries are examples of how to use PAC, HAL and BSP libraries, they aren't in themselves the HAL or anything.
| "-C", | ||
| "link-arg=-Tlink.x", | ||
| ], | ||
| target_compatible_with = ["@platforms//os:none"], |
There was a problem hiding this comment.
Where do you specify the architecture?
There was a problem hiding this comment.
Will this file be included in the generated exercise template that students download? We should make sure it isn't, as it presumably won't work in that context and will be confusing.
There was a problem hiding this comment.
Ditto, we should make sure this isn't included in the exercise template to confuse students.
|
|
||
| echo "Running rtc.bin under QEMU..." | ||
| if [ -n "$NON_INTERACTIVE" ]; then | ||
| echo "q" | qemu-system-aarch64 -machine virt,gic-version=3 -cpu max -serial mon:stdio -display none -kernel "$BIN_PATH" |
There was a problem hiding this comment.
What is the point of this? The model solution doesn't read any input from the serial console.
| "aarch64-unknown-none", | ||
| ], | ||
| ) | ||
| use_repo(crate, "bare_metal_alloc_example") |
There was a problem hiding this comment.
Why do we need both these and the build files in the various directories? How do they interact?
|
Thanks for the explanation! We use bazel at $WORK too and roughly the same experience: conceptually really need, in practice lots of unexpected sharp edges! |
This configures Bazel targets for the bare-metal examples. We now also
have test targets for them:
bazel test //:bare_metal_tests
will compile all the code and run a simple test in QEMU (boot the
binaries, send `"q"` to them on stdin).
The Cargo-based workflow has been kept: I expect that students will
keep using it in class, so we should keep testing it in CI.
mgeisler
force-pushed
the
bazel-bare-metal
branch
from
5f19e2c to
a97dfe8
Compare
3 participants
This configures Bazel targets for the bare-metal examples. We now also have test targets for them:
will compile all the code and run a simple test in QEMU (boot the binaries, send
"q"to them on stdin).The Cargo-based workflow has been kept: I expect that students will keep using it in class, so we should keep testing it in CI.