WIP, POC: Add LLVM support for AVR

[maribu]

Contribution description

This PR is working towards adding LLVM support for the AVR platform.

WARNING: This is work in progress and not in a shape in which it makes sense to start a code review.

I needed to add some workarounds for features of the avrlibc that do not compile with clang. One big pain point is that clang verifies constraints of inline assembly before eliminating dead branches, while GCC does it the other way round. E.g. something like

static inline __attribute__((always_inline)) uint8_t get_foo(void)
{
    uint8_t dest;
    if (FOO < 64) {
         __asm__(
            "in r0,%[foo] \r\n"
            : [dest] "=r"(dest)
            : [foo] "I"(foo)
        );
    }
    else {
        dest = *_SFR_MEM_ADDR(FOO);
    }
    return dest;
}

will fail to compile for FOO >= 64 with LLVM, despite the inline assembly never being executed in that case. The header in <avr/wdt.h> uses this a lot, so I provided versions of wdt_enable() etc. inline - I'm not sure if those will work on al AT(X)mega MCUs supported by RIOT, though.

Another issue with LLVM is that commonly used helpers like __tmp_reg__, __SREG__, __SP_L__, __SP_H__ are not available. For now, I replaced them with magic numbers / register names.

Testing procedure

$ make BOARD=atmega328p TOOLCHAIN=llvm -C examples/hello-world compiles and links, but cannot be flashed.

Issues/PRs references

Depends on:

• core/rmutex: use atomic utils #16919
• cpu/{atxmega,atmega_common}: fix invalid use of PSTR() #16920
• cpu/avr8_common: Fix link with binutils > 2.35.2 #16790

[maribu]

@chrysn: Since you seemed to be interested in using LLVM with AVR: I dumped my current state of work here. It does at least compile and link finally, but it cannot be flashed for now...

[chrysn]

Thanks, and I appreciate any WIP PRs as they make sure that it's findable -- but to clarify: I have no interest in AVR itself (last project had on it was >10a ago, not looking back), it was just that #16919 means that I can avoid the mess the C2Rust transpiler makes of C11 atomics by telling it to go through the atomic utils instead.

(Staying subscribed as in general I like having LLVM usable more widely -- it opens up cross-language-LTO opportunities.)

[benpicco]

This one needs a rebase

[maribu]

Indeed :) But more importantly, it also depends on some infrastructure work. First, llvm/llvm-project#51557 needs to be resolved. Afterwards, the avrlibc headers need to be fixed to be compatible with clang.

Since the avrlibc was recently resurrected, this seems to be quite feasible actually :)

[maribu]

LLVM14 will contain support for the register aliases and the AVR backend has received quite some attention. Also avr-libc became active maintenance again, so I guess I can just aim for fixing things upstream first.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[Teufelchen1]

@maribu Still working on this?

[maribu]

I think some work on LLVMs AVR support has been merged since the last time I looked. Maybe now is a good time to pick this up again.

There are some bugs in avrlibc that GCC doesn't trigger, that can cause a headache. Upstream is pretty much dead for avrlibc.

[Teufelchen1]

Reminder: Soft-freeze is on the 25th.

[maribu]

This does actually compile now on both LLVM and GCC. There are still some rough corners, but this may be on track to get in prior to the soft feature freeze.

[Teufelchen1]

WARNING: This is work in progress and not in a shape in which it makes sense to start a code review.

Can we do reviewing now?

[riot-ci]

Murdock results

❌ FAILED

470564e cpu/avr8_common: Add support for LLVM

Success	Failures	Total	Runtime
1	0	9019	01m:22s

Artifacts

[maribu]

Looks like there are still compilation issues with GCC (at least the old version) that need fixing and static tests. I'm also not happy with the quality yet.

But I split out the commit that I think is ready, though: #20483