Compiling NuttX with system stdlib instead of custom stdlib
Hello, I'm working on a project where I need to compile the NuttX kernel to use the system's standard library (stdlib) instead of its custom implementation. My goal is to have NuttX use the host system's stdlib functions rather than the ones provided with the kernel. Currently, I'm compiling the Nuttx kernel for "sim:posix_spawn" which guarantees native linux support. I'd appreciate any guidance on how to achieve this. Specifically: 1. What configuration changes are needed to disable NuttX's built-in libc? 2. Are there any known issues or challenges in making this change? Any insights in this regard would be greatly appreciated. Regards, Ritvik
Re: Compiling NuttX with system stdlib instead of custom stdlib
Hi Ritvik, I think currently we don't have a "drop-in" replacement for NuttX libc with external libc like musl and others, but it is something easy to do with existing configuration: Look at libs/libc/machine/Kconfig after line 47 you can define that your ARCH has its own libc function. In fact this is how ESP32 and other chips do it to use the internal ROM libc implementation. Search for LIBC_ARCH_MEMCPY at arch/xtensa/Kconfig and memcpy at boards/xtensa/esp32/common/scripts/esp32_rom.ld BR, Alan On Fri, Aug 2, 2024 at 3:06 PM Ritvik Tanksalkar wrote: > Hello, > > I'm working on a project where I need to compile the NuttX kernel to use > the system's standard library (stdlib) instead of its custom > implementation. My goal is to have NuttX use the host system's stdlib > functions rather than the ones provided with the kernel. > > Currently, I'm compiling the Nuttx kernel for "sim:posix_spawn" which > guarantees native linux support. > > I'd appreciate any guidance on how to achieve this. Specifically: > > 1. What configuration changes are needed to disable NuttX's built-in libc? > 2. Are there any known issues or challenges in making this change? > > Any insights in this regard would be greatly appreciated. > > Regards, > Ritvik >
Re: Compiling NuttX with system stdlib instead of custom stdlib
On 8/2/2024 12:06 PM, Ritvik Tanksalkar wrote: Hello, I'm working on a project where I need to compile the NuttX kernel to use the system's standard library (stdlib) instead of its custom implementation. My goal is to have NuttX use the host system's stdlib functions rather than the ones provided with the kernel. Currently, I'm compiling the Nuttx kernel for "sim:posix_spawn" which guarantees native linux support. I'd appreciate any guidance on how to achieve this. Specifically: 1. What configuration changes are needed to disable NuttX's built-in libc? 2. Are there any known issues or challenges in making this change? Any insights in this regard would be greatly appreciated. Regards, Ritvik Almost nothing is impossible given enough effort. But if you are thinking in terms of a simple effort, the simple answer is that replacing the NuttX-specific libc with a Linux-specific libc is impossible. That is because the NuttX libc uses the NuttX OS system calls and the Linux libc uses the Linux system calls. They are not the same. In order to make this work, you would have to change the OS interface used in GLIBC to use the NuttX OS interface. That would be an enormous job! GLIBC uses the Linux-specific header files that you will find under /usr/include/sys. Those would all have to be replaced with NuttX-specific header files. The exported NuttX header files are the ones you find in nuttx/include/nuttx. Most of the header file required by GLIBC don't even exist in NuttX and would have to be created to satisfy GLIBC. That is another enormous job. Alan's suggestion works fine for a few, specific, leaf functions in GLIBC but will not work in general. That is because many non-leaf GLIBC header files will draw in other header files that are not compatible with NuttX. It would be yet another enormous job to make that work. My recommendatioin: Don't waste your time.
Re: Compiling NuttX with system stdlib instead of custom stdlib
Hi, Thank you so much for the valuable insights Gregory and Alan. I kind of understood the pitfalls but nevertheless wanted to confirm. Regards, Ritvik On Fri, Aug 2, 2024 at 3:49 PM Gregory Nutt wrote: > On 8/2/2024 12:06 PM, Ritvik Tanksalkar wrote: > > Hello, > > > > I'm working on a project where I need to compile the NuttX kernel to use > > the system's standard library (stdlib) instead of its custom > > implementation. My goal is to have NuttX use the host system's stdlib > > functions rather than the ones provided with the kernel. > > > > Currently, I'm compiling the Nuttx kernel for "sim:posix_spawn" which > > guarantees native linux support. > > > > I'd appreciate any guidance on how to achieve this. Specifically: > > > > 1. What configuration changes are needed to disable NuttX's built-in > libc? > > 2. Are there any known issues or challenges in making this change? > > > > Any insights in this regard would be greatly appreciated. > > > > Regards, > > Ritvik > > > Almost nothing is impossible given enough effort. But if you are > thinking in terms of a simple effort, the simple answer is that > replacing the NuttX-specific libc with a Linux-specific libc is > impossible. That is because the NuttX libc uses the NuttX OS system > calls and the Linux libc uses the Linux system calls. They are not the > same. In order to make this work, you would have to change the OS > interface used in GLIBC to use the NuttX OS interface. That would be an > enormous job! > > GLIBC uses the Linux-specific header files that you will find under > /usr/include/sys. Those would all have to be replaced with > NuttX-specific header files. The exported NuttX header files are the > ones you find in nuttx/include/nuttx. Most of the header file required > by GLIBC don't even exist in NuttX and would have to be created to > satisfy GLIBC. That is another enormous job. > > Alan's suggestion works fine for a few, specific, leaf functions in > GLIBC but will not work in general. That is because many non-leaf GLIBC > header files will draw in other header files that are not compatible > with NuttX. It would be yet another enormous job to make that work. > > My recommendatioin: Don't waste your time. > > >
Re: Compiling NuttX with system stdlib instead of custom stdlib
Could you tell us a bit about what problem you're trying to solve by using the host system's glibc? As Greg explained, that isn't really feasible, but perhaps if we understand what you're trying to accomplish, someone might be able to suggest a different approach... Cheers Nathan On Fri, Aug 2, 2024 at 4:15 PM Ritvik Tanksalkar wrote: > Hi, > > Thank you so much for the valuable insights Gregory and Alan. I kind of > understood the pitfalls but nevertheless wanted to confirm. > > Regards, > Ritvik > > > > On Fri, Aug 2, 2024 at 3:49 PM Gregory Nutt wrote: > > > On 8/2/2024 12:06 PM, Ritvik Tanksalkar wrote: > > > Hello, > > > > > > I'm working on a project where I need to compile the NuttX kernel to > use > > > the system's standard library (stdlib) instead of its custom > > > implementation. My goal is to have NuttX use the host system's stdlib > > > functions rather than the ones provided with the kernel. > > > > > > Currently, I'm compiling the Nuttx kernel for "sim:posix_spawn" which > > > guarantees native linux support. > > > > > > I'd appreciate any guidance on how to achieve this. Specifically: > > > > > > 1. What configuration changes are needed to disable NuttX's built-in > > libc? > > > 2. Are there any known issues or challenges in making this change? > > > > > > Any insights in this regard would be greatly appreciated. > > > > > > Regards, > > > Ritvik > > > > > Almost nothing is impossible given enough effort. But if you are > > thinking in terms of a simple effort, the simple answer is that > > replacing the NuttX-specific libc with a Linux-specific libc is > > impossible. That is because the NuttX libc uses the NuttX OS system > > calls and the Linux libc uses the Linux system calls. They are not the > > same. In order to make this work, you would have to change the OS > > interface used in GLIBC to use the NuttX OS interface. That would be an > > enormous job! > > > > GLIBC uses the Linux-specific header files that you will find under > > /usr/include/sys. Those would all have to be replaced with > > NuttX-specific header files. The exported NuttX header files are the > > ones you find in nuttx/include/nuttx. Most of the header file required > > by GLIBC don't even exist in NuttX and would have to be created to > > satisfy GLIBC. That is another enormous job. > > > > Alan's suggestion works fine for a few, specific, leaf functions in > > GLIBC but will not work in general. That is because many non-leaf GLIBC > > header files will draw in other header files that are not compatible > > with NuttX. It would be yet another enormous job to make that work. > > > > My recommendatioin: Don't waste your time. > > > > > > >
Re: aarch64 boot crash when printing non-static string
Hello, Thank you Petro for the help! I've taken a look over the past couple days, tried a few different variations, and I'm still very confused by what's going on. You're correct that the program seems to get stuck when I print a string which is *not* marked as `static` in `arm64_earlyprintinit` (printing the static string works just fine). What I'm still confused about is the failing of the assembly `PRINT` macro. This macro marks any string passed to it as being in the `.rodata.str` section, which is the same section that my statically declared string from C code has been put in. This is not on the stack, so there is something else wrong (if not in addition to the stack issues). I have disassembled and inspected the generated binary using `objdump`, and everything seems correct: the address of the strings in .rodata are loaded into a register, the string is iterated over like an array and the `arm64_lowputc` function is called to print each character. The string data is present in the .rodata section. The addresses are seemingly all correct in the disassembly, the binary is loaded fully into RAM at the correct load address, etc. Yet still, garbage is printed to the screen when the first `PRINT` macro call is reached. I have tested calling `arm64_lowputc` from assembly with a character value placed in `w0` to be passed as the argument, which works. I've tested printing static strings from a C function call, which works as well. I've tested commenting out some of the earlier function calls to the `arm64_boot_primary_c_routine` and `arm64_data_initialize` with no difference in results. This same `PRINT` macro works just fine when tested with the same boot sequence on QEMU (and presumably for all the other arm64 platforms merged into NuttX), so something has to be wrong with my implementation. I am struggling to figure out what difference has caused the issue though, as my linker script is almost identical to the other arm64 implementations outside of requiring a different load address. It seems to not be an issue with the `lowputc` functions either, as printing is working with static strings declared in C code. Any ideas of where else I can look? Thank you, Matteo On Thu, Aug 1, 2024 at 12:14 AM Petro Karashchenko < petro.karashche...@gmail.com> wrote: > Hi, > > Based on what you describe it seems like a stack configuration issue. About > "but the > `uint8_t i` variable I use as a counter in my for-loop is working just > fine" -- I think that the compiler just optimizes out loop variable and > does not use stack for it. There are a few things here to try here. You can > try to add "static" to your strings that you are trying to print, so those > will be not placed on stack (not sure if they are now). If you confirm that > the issue is with printing strings located on stack then you can focus on > making sure that stack pointer is pointing to valid memory. > > Best regards, > Petro > > чт, 1 серп. 2024 р. о 03:13 Matteo Golin пише: > > > Hello all, > > > > I've been working on this problem for a while now and I'm not quite sure > > how to progress in my troubleshooting. > > > > I am trying to port NuttX to the Raspberry Pi 4B, which has been going > well > > thanks to the documentation suggestions from my previous email > (especially > > Lup's blogs which have been invaluable). > > > > There is an option for aarch64 to enable early printing within the NuttX > > boot sequence. This enables the use of a PRINT macro > > < > > > https://github.com/apache/nuttx/blob/fe45d8aace2683b212e4ca2b9166a5df93c760fe/arch/arm64/src/common/arm64_head.S#L63 > > > > > in the startup code which is quite useful to me as debug output to see > how > > far along the boot is getting. > > > > I have been able to implement the `lowputc` requirements to enable early > > printing, but I am encountering what I consider to be a strange issue. > > My `arm64_earlyprintinit` > > function > > < > > > https://github.com/apache/nuttx/blob/fe45d8aace2683b212e4ca2b9166a5df93c760fe/arch/arm64/src/common/arm64_head.S#L215 > > > > > is being called and executed just fine, and same for the `arm64_lowputc` > > function. I expected to see the output of the PRINT macros in my serial > > console, but just got some garbled output followed by a crash (indicated > by > > the Pi LED). I thought I had configured the UART wrong, but after some > > debugging involving adding direct calls to `arm64_lowputc` at the end of > > the `arm64_earlyprintinit`, I saw that UART was configured just fine > > because I was able to see the characters printed by my direct calls. > > > > My next step was to print a string like "Hello NuttX!", so I did that by > > using `arm64_lowputc` calls in a for loop. This didn't work, and I got > some > > garbled output again. After some more tinkering, I discovered that if I > > marked the string literal as `static`, my printing in a for-loop > succeeded. > > I thought maybe this was a problem with the stack initialization, but t
