| 98d863a5 | 05-Jul-2019 |
Jerome Forissier <jerome@forissier.org> |
Experimental Clang support
Allows building with Clang with "make COMPILER=clang [other flags...]".
The clang command has to be in the $PATH, as well as the associated
tools (clang-cpp, ld.lld, llvm-
Experimental Clang support
Allows building with Clang with "make COMPILER=clang [other flags...]".
The clang command has to be in the $PATH, as well as the associated
tools (clang-cpp, ld.lld, llvm-ar, llvm-nm, llvm-objcopy and
llvm-readelf).
Tested with Clang built from the master branch of [1] (development
version for 9.0):
mkdir build; cd build
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=~/llvm-install \
-DLLVM_ENABLE_PROJECTS="clang;lld" \
-DLLVM_TARGETS_TO_BUILD="AArch64;ARM" \
~/llvm-project/llvm
ninja && ninja install
Limitations:
- CFG_CORE_SANITIZE_KADDRESS=y is not supported.
- CFG_WITH_PAGER is supported, but requires that the TEE core be
linked with the GNU linker. The reason is documented in
mk/clang.mk.
Bug:
- ldelf assertion failure in xtest 1019 when CFG_ULIBS_SHARED=y (QEMU)
E/LD: assertion 'maps[map_idx].sz == sz' failed at ldelf/ta_elf.c:1114 in ta_elf_print_mappings()
Prevents ldelf from displaying the TA mappings on abort or panic, but
does not seem to cause any other problem.
Link: [1] https://github.com/llvm/llvm-project/commits/8351c327647
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Tested-by: Jerome Forissier <jerome@forissier.org> (QEMU pager/no pager)
Tested-by: Jerome Forissier <jerome@forissier.org> (QEMUv8, pager/no pager)
Tested-by: Jerome Forissier <jerome@forissier.org> (HiKey960, 32/64, GP)
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| e29072bd | 11-Sep-2019 |
Jerome Forissier <jerome@forissier.org> |
Revert "compiler.h: introduce GCC version check"
This reverts commit fc78b3ffc59ef03e599ae952b4345f03f466f11c and
updates the comment in <compiler.h>.
It turns out not only GCC 8.x needs the workar
Revert "compiler.h: introduce GCC version check"
This reverts commit fc78b3ffc59ef03e599ae952b4345f03f466f11c and
updates the comment in <compiler.h>.
It turns out not only GCC 8.x needs the workaround. I tried 4.9, 6.2,
8.2, and 8.3 from various sources (Linaro or Ubuntu). If
__SECTION_FLAGS_RODATA is empty, this warning is always present:
CC out/arm-plat-vexpress/core/mm/fobj.o
{standard input}: Assembler messages:
{standard input}:402: Warning: setting incorrect section attributes for .rodata.__unpaged
The generated assembler file contains the "aw" flags:
$ grep '\.section.*\.rodata\.__unpaged' out/arm-plat-vexpress/core/mm/fobj.s
.section .rodata.__unpaged,"aw",%progbits
By reverting the above commit, we have:
$ grep '\.section.*\.rodata\.__unpaged' out/arm-plat-vexpress/core/mm/fobj.s
.section .rodata.__unpaged,"a",%progbits //,"aw",%progbits
...and the assembler does not warn anymore.
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| 7c8b181a | 25-Feb-2019 |
Jerome Forissier <jerome.forissier@linaro.org> |
libutils: add memzero_explicit()
Adds a new function: memzero_explicit(s, count) which is equivalent to
memset(s, 0, count) except that it cannot be optimized away by the
compiler.
memset() being a
libutils: add memzero_explicit()
Adds a new function: memzero_explicit(s, count) which is equivalent to
memset(s, 0, count) except that it cannot be optimized away by the
compiler.
memset() being a built-in function, the compiler is free to perform
optimizations such as simply discarding a call when it considers that the
call cannot have any observable effect from the program's point of view.
A typical example is clearing local data before returning from a
function. memset() is likely to have no effect in this case while
memzero_explicit() will work as expected.
Calling memset() directly from memzero_explicit() would work as long as
link time optimization (LTO) is not applied. With LTO however, the
compiler could inline the call to memzero_explicit() and find out that
dead store optimization applies. In order to avoid that, we use a method
mentioned in [1] which consists in using a volatile function pointer.
This method is considered "effective in practice" with all the commonly
used compilers.
Link: [1] https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-yang.pdf
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
show more ...
|
| b0d497fa | 20-Dec-2018 |
Jerome Forissier <jerome.forissier@linaro.org> |
libutils: export PRIxVA_WIDTH and add PRIxPA_WIDTH
Export two macros that are useful to print virtual or physical addresses
with the full width required by the native type, that is, 0x + 8
character
libutils: export PRIxVA_WIDTH and add PRIxPA_WIDTH
Export two macros that are useful to print virtual or physical addresses
with the full width required by the native type, that is, 0x + 8
characters when the pointer size is 32 bits, and 0x + 16 characters when
it is 64 bits.
Example:
vaddr_t va = 0x1234;
DMSG("va=0x%0*" PRIxVA, PRIxVA_WIDTH, va);
The above code will print "va=0x00001234" if vaddr_t is 32 bits, and
"va=0x0000000000001234" if vaddr_t is 64 bits.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| 48e10604 | 14-Feb-2019 |
Jerome Forissier <jerome.forissier@linaro.org> |
libutils: remove buf_compare_ct()
Now that we have consttime_memcmp(), buf_compare_ct() is redundant.
Every time buf_compare_ct() is used, consttime_memcmp() may be used
instead.
This commit remove
libutils: remove buf_compare_ct()
Now that we have consttime_memcmp(), buf_compare_ct() is redundant.
Every time buf_compare_ct() is used, consttime_memcmp() may be used
instead.
This commit removes buf_compare_ct(). A compatibility wrapper is kept
in <string_ext.h> to avoid knowingly breaking the build of any TA that
may use it.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|