Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
The ELF loader needs to load the app into the memory before
executing it from the same location. As expected, this memory space
should be able to execute code. For architectures containing data
and instruction buses, the instruction bus may not be able to be
accessed in a non-aligned way, which is usually required when
copying data to that location. Eventually, this same memory space
can be accessed through the data bus, using different address
ranges. This commit enables accessing the memory through the data
bus to copy the app's data before executing it when
`CONFIG_ARCH_HAVE_TEXT_HEAP_WORD_ALIGNED_READ` is enabled.
There is a problem with the current elf loader for risc-v: when a pair of
PCREL_HI20 / LO12 relocations are encountered, it is assumed that these
will follow each other immediately, as follows:
label:
auipc a0, %pcrel_hi(symbol) // R_RISCV_PCREL_HI20
load/store a0, %pcrel_lo(label)(a0) // R_RISCV_PCREL_LO12_I/S
With this assumption, the hi/lo relocations are both done when a hi20
relocation entry is encountered, first to the current instruction (addr)
and to the next instruction (addr + 4).
However, this assumption is wrong. There is nothing in the elf relocation
specification[1] that mandates this. Thus, the hi/lo relocation always
needs to first fixup the hi-part, and when the lo-part is encountered, it
needs to find the corresponding hi relocation entry, via the given "label".
This necessitates (re-)visiting the relocation entries for the current
section as well as looking for "label" in the symbol table.
The NuttX elf loader does not allow such operations to be done in the
machine specific part, so this patch fixes the relocation issue by
introducing an architecture specific cache for the hi20 relocation and
symbol table entries. When a lo12 relocation is encountered, the cache
can be consulted to find the hi20 part.
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc
Provide a way to only customize specific string operations,
such as for memcpy with the DMA capability by ROM.
Signed-off-by: yangdongdong <yangdongdong@xiaomi.com>
1. Update all CMakeLists.txt to adapt to new layout
2. Fix cmake build break
3. Update all new file license
4. Fully compatible with current compilation environment(use configure.sh or cmake as you choose)
------------------
How to test
From within nuttx/. Configure:
cmake -B build -DBOARD_CONFIG=sim/nsh -GNinja
cmake -B build -DBOARD_CONFIG=sim:nsh -GNinja
cmake -B build -DBOARD_CONFIG=sabre-6quad/smp -GNinja
cmake -B build -DBOARD_CONFIG=lm3s6965-ek/qemu-flat -GNinja
(or full path in custom board) :
cmake -B build -DBOARD_CONFIG=$PWD/boards/sim/sim/sim/configs/nsh -GNinja
This uses ninja generator (install with sudo apt install ninja-build). To build:
$ cmake --build build
menuconfig:
$ cmake --build build -t menuconfig
--------------------------
2. cmake/build: reformat the cmake style by cmake-format
https://github.com/cheshirekow/cmake_format
$ pip install cmakelang
$ for i in `find -name CMakeLists.txt`;do cmake-format $i -o $i;done
$ for i in `find -name *\.cmake`;do cmake-format $i -o $i;done
Co-authored-by: Matias N <matias@protobits.dev>
Signed-off-by: chao an <anchao@xiaomi.com>
since symbols defined in arch/elf.h is also used in other case, for example:
CC: pthread/pthread_testcancel.c machine/arm/gnu_unwind_find_exidx.c:32:8: error: unknown type name '__EIT_entry'
32 | static __EIT_entry *__exidx_start_elf;
| ^~~~~~~~~~~
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Add the `LIBC_PREVENT_STRING_KERNEL` and `LIBC_PREVENT_STRING_USER`
that are meant to be selected by the chip if no libc implementation
is going to be built. If selected, neither NuttX's software version
of the libc nor any architecture-specific implementation will be
built in the kernel or in the userspace, respectively. In this
case, the linker may provide a ROM-defined version of the libc
functions instead.
In order to turn longjmp context-switch safe, it's necessary
to disable interrupts before modifying windowbase and windowstart.
Otherwise, after a context switch, windowstart and windowbase
would be different, leading to a wrongly set windowstart bit due to
longjmp writing it based on the windowbase before the context switch.
This corrupts the registers at the next window overflow reaching
that wrongly set bit.
*Background:*
This PR is related to an issue first observed on ESP-IDF
https://github.com/espressif/esp-idf/issues/5229 and it was, then,
checked on NuttX using a test application.
*The test application:*
To check if the problem affects ESP32, ESP32-S2 and ESP32-S3 on
NuttX, it was created an application based on:
https://en.cppreference.com/w/c/program/longjmp
The application creates 16 tasks (`#define NUMBER_OF_TASKS 16`)
that implements the following daemon:
```
static int setjmp_longjmp_daemon(int argc, char *argv[])
{
for (int i = 0; i < NUMBER_OF_TASKS * 2; i++)
{
jmp_buf env;
volatile int count = 0;
if (setjmp(env) != UINT16_MAX)
{
foo(&env, ++count);
}
}
sem_post(&g_sem);
return EXIT_SUCCESS;
}
```
The main function also initializes a semaphore to avoid application
exiting before tasks return successfully:
```
sem_init(&g_sem, 0, -NUMBER_OF_TASKS);
```
Finally, the round-robin interval was lowered to 1ms to raise the
chances of the longjmp being interrupted by a context switch
(`CONFIG_RR_INTERVAL=1).
This setup was able to reproduce the problem prior to this patch
being applied.
Alin Jerpelea