Add LLVM libc sample

[smithp35]

This will be built into the LLVM libc overlay package. Sample installs to samples/src/llvmlibc/baremetal-semihosting.

• Add llvmlibc-samples directory to contain LLVM libc specific samples.
• Add single baremetal-semihosting sample using LLVM libc.

Sample contains a number of calls to LLVM libc functionality:

• heap.
• printf.
• string library.
• math library.

A special linker script is used to set the bounds of the heap. This uses different linker defined symbols to picolibc.

The crt0.S from the existing llvmlibc-support can't be used directly as the RW and ZI from the linker script need initializing.

[pratlucas]

What's the motivation for using a separate directory structure instead of placing the new samples inside the existing samples directory?

[smithp35]

What's the motivation for using a separate directory structure instead of placing the new samples inside the existing samples directory?

A couple of reasons, neither particularly strong:

• Easier to avoid name clashing with the existing picolibc samples as the overlay package is developed separately. This could be resolved by explicitly adding llvmlibc to each sample name, for example baremetal-semihosting-llvmlibc.
• It made it easier for me to remove the llvm-libc samples when repeatedly testing the package, but I think that's resolvable.

I'm open to opinions on what's best?

[pratlucas]

What's the motivation for using a separate directory structure instead of placing the new samples inside the existing samples directory?

A couple of reasons, neither particularly strong:

• Easier to avoid name clashing with the existing picolibc samples as the overlay package is developed separately. This could be resolved by explicitly adding llvmlibc to each sample name, for example baremetal-semihosting-llvmlibc.
• It made it easier for me to remove the llvm-libc samples when repeatedly testing the package, but I think that's resolvable.

I'm open to opinions on what's best?

For consistency I'd suggest keeping everything under samples. It also helps to keep the directory structure simple and clear.

Could we maybe have separate sub-sirectories inside samples for each library package we provide? E.g.:

LLVM-embedded-toolchain-for-Arm/
├─ samples/
│  ├─ picolibc/
│  ├─ newlib/
│  ├─ llvmlibc/
├─ ...

[smithp35]

What's the motivation for using a separate directory structure instead of placing the new samples inside the existing samples directory?

A couple of reasons, neither particularly strong:

• Easier to avoid name clashing with the existing picolibc samples as the overlay package is developed separately. This could be resolved by explicitly adding llvmlibc to each sample name, for example baremetal-semihosting-llvmlibc.
• It made it easier for me to remove the llvm-libc samples when repeatedly testing the package, but I think that's resolvable.

I'm open to opinions on what's best?

For consistency I'd suggest keeping everything under samples. It also helps to keep the directory structure simple and clear.

Could we maybe have separate sub-sirectories inside samples for each library package we provide? E.g.:

LLVM-embedded-toolchain-for-Arm/
├─ samples/
│  ├─ picolibc/
│  ├─ newlib/
│  ├─ llvmlibc/
├─ ...

Are you OK with me doing that in a follow up change as this one currently only affects the overlay package?