Help with setting up ARM embedded clang + lld

Hi all,
I've been doing a ton of embedded work (bare metal ARM Cortex M0+ and
M4, hopefully RISCV in the future) in the last year and would love to
start using and hacking on the llvm toolchain. I've tried setting up
clang + lld but can't get lld to work because clang tries to launch gcc.
I realize support is early but I'd love to have a dev setup so I can
help fix things.

Could some help me setup my Makefiles in this project:
GitHub - tannewt/circuitpython at clang to use dev builds of
clang and lld? Thanks!
~Scott

Did you read http://lld.llvm.org/#using-lld? In short, you want to pass -use-ld=lld to clang to use ld.lld instead of ld.

clang doesn't know how to call a linker for baremetal, so it tries to
fallback to gcc. Just call the linker directly.

Joerg

I did look at that and it doesn’t work. Here is the line from the Makefile: https://github.com/tannewt/circuitpython/blob/clang/atmel-samd/Makefile#L300

And here is it as output from make:

clang version 5.0.0 (trunk 301735)

Target: armv6m-none–eabi

Thread model: posix

InstalledDir: /Users/tannewt/repos/llvm/build/bin

“gcc” -flto -v -fuse-ld=lld -march=thumb…

clang-5.0: error: unable to execute command: Executable “gcc” doesn’t exist!clang-5.0: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)

Ok, thanks! I got it going that way. I'd still love to hear from anyone
off list working on similar stuff.
~Scott

I’m interested in supporting embedded programs as well as supporting RISC-V. Let me know if I can help you.

Hi Scott,

Peter (CC'd) is implementing support for ARM32 on LLD. There are a few
missing pieces, but most support has been upstreamed already.

AFAIK, the most important missing features are range extension chunks
(important for large code base, like Clang) and better support for
linker script files (more important to embedded cases, like yours).

Apart from that, "it should just work". :slight_smile:

Let us know if you find anything else. Adding a bug to bugzilla and
copying us (in this thread, including Rui, Joerg, me, Peter) would be
the best way to fix issues.

cheers,
--renato

Awesome! I got lld running but it GCed all my sections away. :slight_smile: I'll
keep experimenting with it.
~Scott

That’s interesting. Usually your code wouldn’t be gc’ed because your entire code is reachable from _start.

Does your program depend on the feature that, if no -e option is given, the linker sets the beginning of the .text section to the entry point address?

That's interesting. Usually your code wouldn't be gc'ed because your entire
code is reachable from _start.

Baremetal doesn't need a _start.

Does your program depend on the feature that, if no -e option is given, the
linker sets the beginning of the .text section to the entry point address?

I believe that would help, yes. But there may be linker scripts that
can change that, so you need to be careful.

cheers,
--renato

If you want to do GC, you still need to teach linkers GC root symbols in
some way, no? Otherwise, linkers cannot determine if a section is live or
not.

Yeah totally. I had marked some sections as used previously but haven’t had a chance to look further into it. I’ll try to take some time this weekend to poke at it further.

The project I’m working on is here: https://github.com/tannewt/circuitpython/tree/clang/atmel-samd in case you can’t wait.

Thanks,

Scott

> That's interesting. Usually your code wouldn't be gc'ed because your
entire
> code is reachable from _start.

Baremetal doesn't need a _start.

> Does your program depend on the feature that, if no -e option is given,
the
> linker sets the beginning of the .text section to the entry point
address?

I believe that would help, yes. But there may be linker scripts that
can change that, so you need to be careful.

If you want to do GC, you still need to teach linkers GC root symbols in
some way, no? Otherwise, linkers cannot determine if a section is live or
not.

Yeah totally. I had marked some sections as used previously but haven't
had a chance to look further into it. I'll try to take some time this
weekend to poke at it further.

The project I'm working on is here: https://github.com/tannewt/
circuitpython/tree/clang/atmel-samd in case you can't wait.

Staring at the makefile, it seems like -flto is used, which might run into
the same "GC" related issue I was describing here about linker script KEEP
directives not being factored into the internalization logic with LTO:
http://lists.llvm.org/pipermail/llvm-dev/2017-February/110582.html

I don't think we ever got a reproducer for that issue though. If removing
-flto fixes the GC issue (or the __attribute__((used)) workaround I
describe in the link works), could you add `--reproduce repro.tar` to your
LLD invocation and upload repro.tar in a bug report?

-- Sean Silva