CXX: libcxx/libcxx/src/random.cpp In file included from nuttx/include/libcxx/__filesystem/filesystem_error.h:15,
from nuttx/include/libcxx/__filesystem/directory_entry.h:20,
from nuttx/include/libcxx/filesystem:539,
from nuttx/include/libcxx/fstream:192,
from libcxx/libcxx/src/ios.instantiations.cpp:10:
nuttx/include/libcxx/__filesystem/path.h: In instantiation of 'std::__1::__fs::filesystem::path::_EnableIfPathable<_Source> std::__1::__fs::filesystem::path::append(const _Source&) [with _Source = std::__1::basic_string<char>]':
nuttx/include/libcxx/__filesystem/path.h:623:30: error: use of built-in trait '__remove_pointer(typename std::__1::decay<_Tp>::type)' in function signature; use library traits instead
623 | _EnableIfPathable<_Source> append(const _Source& __src) {
| ^~~~~~
Pick the change from llvm-project:
https://github.com/llvm/llvm-project/pull/92663
Signed-off-by: chao an <anchao.archer@bytedance.com>
Addrenv is changed to the newly created process' one in the beginning of
modlib_bind, and needs to be changed always when returning from the function;
also in error cases.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
1. fix https://github.com/apache/nuttx/issues/14774.
Change the defconfig of libcxxtest and select libcxxabi by default to
fix sim:libcxxtest build in macOS CI can't find cxxabi.h.
2. fix https://github.com/apache/nuttx/issues/15491.
libcxxabi cannot be used with uclibc, so when compiling macos sim, libcxxabi cannot be selected by default in Kconfig.
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
GDB release 16.2 recently to fix the incompatibility issue with LLDB.
For us, the only change is stub must report it support feature 'binary-upload' before GDB will use this feature.
For more information, find bug report and discussion in https://sourceware.org/bugzilla/show_bug.cgi?id=32593
Use GDB 16.2, now it works with binary upload.
```
[remote] Sending packet: $x39c,4#a7
[remote] Received Ack
[remote] Packet received: b\000\203
```
Signed-off-by: Neo Xu <neo.xu1990@gmail.com>
According to https://pubs.opengroup.org/onlinepubs/9799919799/, the
expected behavior for the wcstombs() function is that it should
convert the wide-character codes stoping conversion either when a
character sequence exceeds the limit of n total bytes or if a null
byte is stored. In the first case, the null-terminated value should
not be appended to the dst buffer.
Currently, no null-terminator is appended to the dst buffer, even
when it's expected to be appended, generating erroneous output.
Read/write special data like 0x2a2a2a2a will trigger this issue.
The current GDB implementation has this flaw. GDB processes the RLE
decoding before espaping the data, make it impossible to repeate special
characters.
The details can be seen in GDB source code remote.c
remote_target::read_frame function.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
As armv7-a addrenv layout is not in line with other archs, we need
align it with others by defining ARCH_DATA_RESERVE_SIZE as same as
MM_PGSIZE for now to keep gnu-elf.ld.in unified.
Signed-off-by: Yanfeng Liu <p-liuyanfeng9@xiaomi.com>
Summary:
- Replace direct use of `fence.i` instruction with `__ISB()` macro for instruction synchronization
- This change improves portability while maintaining the same functionality
Impact:
- No functional changes - both `fence.i` and `__ISB()` ensure instruction
synchronization on RISC-V
- Makes the code more maintainable by using the architecture abstraction
layer
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Summary:
- Removed explicit -std=c99 flag from Make.defs
- The project-wide C standard is already set at a higher level
- Keeps build configuration consistent across the codebase
Impact:
- No functional changes to the code
- Maintains consistency with project-wide C standard settings
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
These options are unistd-specific and should not be filesystem dependent,
and also not suitable for define in the sched directory.
Signed-off-by: chao an <anchao.archer@bytedance.com>
arch/risc-v/src/common/riscv_addrenv.c:418:
{
...
database = resvbase + MM_PGALIGNUP(resvsize);
...
}
need use MM_PGALIGNUP(resvsize) inside of ARCH_DATA_RESERVE_SIZE
if not add MM_PGALIGNUP(resvsize), will mismatch address load .data
section
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
It will be used to distinguish between hardware KASan and software KASan. Hardware KASan does not need to use plug-in
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
This generates gnu-elf.ld via preprocessing of gnu-elf.ld.in so
that to reduce board specific app linker scripts in kernel mode
when BINFMT_ELF_EXECUTABLE is enabled.
Signed-off-by: Yanfeng Liu <p-liuyanfeng9@xiaomi.com>
This commit cleans up redundant header file includes throughout the codebase.
The changes include:
- Removing duplicate #include directives that were present in the same file
- Consolidating includes that were split across multiple lines unnecessarily
- Removing unused includes that were no longer needed
- Fixing some formatting issues with includes
The changes improve code organization and maintainability by:
- Reducing unnecessary dependencies
- Making include dependencies more explicit
- Following consistent include patterns
- Removing dead code
No functional changes are made - this is purely a code cleanup commit.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
The POSIX standard states that the `syslog()` function generates
the body from the message and arguments the same way as `printf()`,
> except that the additional conversion specification `%m` shall be
> recognized;
*https://pubs.opengroup.org/onlinepubs/009695399/functions/syslog.html*
What most of the implementations do is to leverage the processing to
`vsprintf` internals, to reduce code duplicity. This means the `%m`
modifier is present on almost all `printf` implementations. Take
the following code snippet as an example: https://onlinegdb.com/YdR9pU6KS.
Therefore, for `syslog` to support such a specification, the underlying
library shall be updated to support it too.
When enable CONFIG_STACK_CANARIES, in general, the stack check in the __gcov_fork function is:
" return fork();
18: e59f3020 ldr r3, [pc, #32] @ 40 <__gcov_fork+0x40>
1c: e5932000 ldr r2, [r3]
20: e59d3004 ldr r3, [sp, #4]
24: e0332002 eors r2, r3, r2
28: e3a03000 mov r3, #0
2c: 1a000002 bne 3c <__gcov_fork+0x3c>"
r3 is obtained by taking the value of sp offset. But after opening thumb, the second comparison value in
"8c6: 4a06 ldr r2, [pc, #24] @ (8e0 <__gcov_fork+0x30>)
8c8: 6811 ldr r1, [r2, #0]
8ca: 687a ldr r2, [r7, #4]
8cc: 4051 eors r1, r2"
is obtained through r7. Since r7 stores the stack address at this time, which stores the address of the parent process, the stack out of bounds will occur in the child process
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
