anjiahao1 opened a new pull request, #3641:
URL: https://github.com/apache/nuttx-apps/pull/3641

   
   ## Summary
   
     * Emits the application's configured stack size and priority (and
       `uid`/`gid`/`mode` under `CONFIG_SCHED_USER_IDENTITY`) as absolute ELF
       symbols (`nx_stacksize`, `nx_priority`, `nx_uid`, `nx_gid`, `nx_mode`)
       via `--defsym` in `MODLDFLAGS`, so the NuttX binary loader can recover
       them at load time.
     * Computes the symbols per target (each `$(PROGLIST)` entry picks up its
       own `STACKSIZE_`/`PRIORITY_`/...), and only emits a symbol when the
       application actually configures that attribute.
     * Keeps the `nx_*` symbols through `--strip-unneeded` (via `-K`) so they
       survive in the stripped runtime image under `bin/`.
     * Skips builtin registration for separately-built module ELFs
       (`BUILD_MODULE` instead of `DYNLIB`), matching the kernel-build model
       where apps are loaded as file ELFs.
     * Related NuttX PR: <nuttx PR link>
   
   ## Impact
   
     * Is new feature added? Is existing feature changed? YES — new feature:
       application attributes are embedded as ELF symbols for the loader.
     * Impact on user (will user need to adapt to change)? NO — attributes are
       only emitted when configured; otherwise behavior is unchanged.
     * Impact on build (will build process change)? YES (minor) — module ELF
       links now carry `--defsym nx_*` flags and the stripped `bin/` image
       retains those symbols.
     * Impact on hardware (will arch(s) / board(s) / driver(s) change)? NO.
     * Impact on documentation (is update required / provided)? NO (not yet).
     * Impact on security (any sort of implications)? NO.
     * Impact on compatibility (backward/forward/interoperability)? NO —
       `heapsize` is intentionally not emitted (depends on the separate
       task-heap feature); a typo in the original (`nx_mod`/wrong source) is
       fixed to `nx_mode` from `MODE`.
     * Anything else to consider or add? Requires the companion NuttX PR that
       teaches `binfmt/elf.c` to parse these symbols.
   
   ## Testing
   
     I confirm that changes are verified on local setup and works as intended:
     * Build Host(s): Ubuntu, arm-none-eabi-gcc 12.2.1
     * Target(s): `qemu-armv7a:knsh` (CONFIG_BUILD_KERNEL), apps built from
       `../apps` and mounted via hostfs as `/system`.
     * Build: `make` then `make install` in the apps tree (kernel-build module
       ELFs).
     * Run command: `qemu-system-arm -semihosting -M virt -m 1024 -nographic 
-kernel ./nuttx`
   
     Testing logs after change (the `getprime` app, configured with
     `STACKSIZE=8192` / `PRIORITY=50`, carries the symbols into the stripped
     runtime ELF, and the loaded task honors them):
   
     ```
     $ arm-none-eabi-nm bin/getprime | grep nx_
     00000032 A nx_priority
     00002000 A nx_stacksize
   
     nsh> getprime 4 &
       TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK      
      STACK    USED FILLED COMMAND
         4     4     3  50 RR       Task      - Waiting  Semaphore 
0000000000000000 0008144 0000792   9.7%  getprime 4
     ```
   
     `hello`, `ostest`, `init` (NSH) all build and run; no regression on
     `knsh`. (`nx_stacksize`/`nx_priority` are retained in `bin/` after
     `--strip-unneeded` thanks to `-K`.)
   
   ## PR verification Self-Check
   
     * [X] This PR introduces only one functional change.
     * [X] I have updated all required description fields above.
     * [X] My PR adheres to Contributing Guidelines and Documentation (git 
commit title and message, coding standard, etc).
     * [ ] My PR is still work in progress (not ready for review).
     * [X] My PR is ready for review and can be safely merged into a codebase.
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to