Embedded Toolchains Roundtable Notes

Community US Developer Meeting
1
  • 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
  • Multilib
    • Data driven multilib doesn’t flag on somethings it should.
    • But it kinda works
2 Likes