- Blessed Devboards (and testing)
- We want to test things upstream for LLVM-libc, clang, etc.
- There are too many targets to test all possible embedded configurations
- It would be useful to pick one or a few example targets that are used for testing
- One suggestion is the Raspberry Pi Pico 2, since it has both ARM and RISC-V processors
- Other architectures than ARM, RISC-V that people care about
- Hexagon
- MIPS
- DSP
- Goal is to do general testing, not necessarily looking for board specific issues
- Is it reasonable to use something like Pigweed for broad testing of lots of functionality
- It would be nice to have something like the LLVM kaleidoscope tutorial, with a specific board it’s targeting
- There is a pigweed tutorial for the Raspberry Pi Pico
- Emulation?
- Is it close enough for testing?
- It’s much more accessible than hardware, especially for more obscure targets (e.g. Hexagon)
- We should probably have QEMU at least as an option
- With semihosting and emulation you can open files on your host system and therefore run a wider range of tests.
- It’s possible to debug a binary running under qemu with lldb, which is very useful for debugging.
- Need to figure out who will run this.
- Is one of the companies willing to run and pay for this?
- Linaro is possibly willing to run emulated tests, but not hardware tests.
- Might want to do unit tests under emulation where it’s cheaper, and then do end-to-end tests on hardware.
- Libc++ needs to be willing to work with this, and there needs to be a buildbot.
- It would be useful to compare test results with the previous run (only show red for tests that are newly breaking, instead of tests that are already broken)
- A narrower test tends to be less flakey, might want to group tests.
- Profile/static image layout
- Daniel Thornburgh gave a talk on this
- Working on using profiles to figure out the best spot on the memory map to place functions
- There’s at Google an observation that 90% of code in embedded projects is cold, so placing it automatically makes sense.
- Similar to FDO, but more embedded specific.
- There’s an embedded linker that does something similar at Qualcomm, they’re thinking about open sourcing it
- Profiles are currently done via the debug probe, could potentially be done with semihosting.
- Both the linker and the compiler need to see the profile.
- People have been doing something similar generating linker scripts based on profiles.
- Blessed Runtime
- Currently there are picolibc buildbots
- Primarily to detect libc++ issues
- In future we’d like to have an LLVM-libc bot as well
- Possibly keep both so that we can ensure libc++ stays independent from LLVM-libc
- Does anyone care about libgcc vs compiler-rt?
- Not much interest in libgcc for embedded
- If you’re setting up a toolchain you’re generally more willing to pick compiler-rt
- Does LLVM-libc support thread local storage?
- Not on embedded right now
- Picolibc does, but through a hacky linker script.
- It’s not very functional right now.
- In ARM’s C library they had a struct to handle thread local variables.
- TLS can be a serious burden, some smaller processors can’t handle it.
- There are higher priority things on LLVM-libc
- E.g. semihosting
- Currently there are picolibc buildbots
- Multilib
- Data driven multilib doesn’t flag on somethings it should.
- But it kinda works
2 Likes