| Lorenz Brun | 605efbe | 2021-09-28 14:01:01 +0200 | [diff] [blame] | 1 | llvm-efi |
| 2 | ======== |
| 3 | |
| 4 | llvm-efi is a Bazel cc toolchain that uses the machine's host LLVM/clang with flags targeting freestanding EFI. |
| 5 | EFI headers are not shipped as part of the toolchain, but are available as a cc_library from `@gnuefi//:gnuefi`. |
| 6 | |
| 7 | At some point, this toolchain should be replaced by a fully hermetic toolchain that doesn't depend on the host environment. |
| 8 | |
| 9 | Usage |
| 10 | ----- |
| 11 | |
| Leopold Schabel | 0ea448a | 2022-03-16 13:49:32 +0100 | [diff] [blame^] | 12 | To use this toolchain explicitly while building a `cc_binary`, do: |
| Lorenz Brun | 605efbe | 2021-09-28 14:01:01 +0200 | [diff] [blame] | 13 | |
| 14 | bazel build --crosstool_top=//build/toolchain/llvm-efi:efi_cc_suite //foo/bar |
| 15 | |
| 16 | During an actual build however, the right toolchain should be selected using aspects or other Bazel configurability features, instead of a hardcoded `--crosstool_top`. |
| 17 | |
| 18 | fltused |
| 19 | ------- |
| 20 | |
| 21 | This is a special symbol emitted by MSVC-compatible compilers. In an EFI environment it can be ignored, but it needs to |
| 22 | be defined. See fltused.c for more information on the symbol. Since we cannot build an object file with Bazel and |
| 23 | building things for toolchains isn't a thing anyways, this file is prebuilt. If this ever needs to be rebuilt (which |
| 24 | will probably never happen since there is only one static symbol in there) this can be done with the following clang |
| 25 | invocation: |
| 26 | |
| 27 | clang -target x86_64-unknown-windows -fno-ms-compatibility -fno-ms-extensions -ffreestanding -o fltused.o .o -c fltused.c |
| 28 | |