v01d edited a comment on pull request #3589: URL: https://github.com/apache/incubator-nuttx/pull/3589#issuecomment-828076813
> No, your understanding is not quite correct. In the FLAT build, only one copy of the libraries is built. The OS and the applications link to the same libraries. For example, libs/libc builds libc.a for both the applications and the OS code. Sorry, I didn't clarify: my question regarding `__KERNEL__` was for FLAT mode. I noticed looking at `LibTargets.mk` that libs, mm and libapps do not ever receive the KDEFINE flags, while other libs do. > In the PROTECTED and KERNEL builds, the applications and OS are separately linked: two blobs for the PROTECTED case and many for the KERNEL case. And two different libraries are built: libuc.a for the user/application space blob and libkc.a for the kernel-space OS blob. These blobs are different because applications and the OS use different different interfaces. The application, for example, never calls directly into the OS but gets into the OS via system calls (call gates that switch from user to supervisor modes). When building the application space library, libuc.a, __KERNEL__ must not be defined. This tells the system that we are building the application space version of the library. For libkc.a, __KERNEL__ must be defined. This tells the build that we are building for code that runs inside the OS. This is done via a two pass build. For the PROTECTED mode, the application blob is built first and linked with the system call proxies. In the second pass, the OS blob i s built and linked with the system call stubs. KERNEL mode is a little different because the applications are build as executable that run from a file system, much like with Linux. Part of the build is manual. That is description in board README's like boards/arm/sama5/sama5d4-ek/README.txt for knsh cconfiguration. Thanks for the explanation, I will look further into how the build is structured with this information. > The simulator also depends on a 2-pass build, but for different reasons. See boards/sim REAME file. Yes, I already have the nuttx.rel + nuttx handled for sim. > Please be careful and don't break. This is pretty complex and delicate logic and critical to the future of the OS. Of course. This will require a great deal of testing and also manual validation of correct build flags being used. There's quite a lot to do still. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
