casaroli opened a new pull request, #19537:
URL: https://github.com/apache/nuttx/pull/19537
## Summary
`apps/Application.mk` stamps each program's configured priority into its ELF
as
an absolute `nx_priority` symbol, and encodes `PRIORITY =
SCHED_PRIORITY_DEFAULT`
as **zero**:
```make
$(PROGLIST): SYM_PRIORITY = $(if $(filter
SCHED_PRIORITY_DEFAULT,$(PRIORITY_$@)),0,$(PRIORITY_$@))
$(PROGLIST): MODLDFLAGS += $(if $(PRIORITY_$@),--defsym
nx_priority=$(SYM_PRIORITY))
```
`elf_loadbinary()` takes that literally:
```c
ret = libelf_findsymbol(&loadinfo, "nx_priority", &sym);
if (ret == 0)
{
binp->priority = sym.st_value; /* 0 means "default", not priority 0 */
}
```
so any program whose `Makefile` declares `PRIORITY = SCHED_PRIORITY_DEFAULT`
—
`testing/ostest` among them — is created at priority 0. That ties with the
idle
task, the new task is queued *behind* it, and it never runs.
The failure gives nothing to go on: the loader reports success,
`binfmt_dumpmodule`
looks normal, the task appears in the task list as READY-TO-RUN, and the
program
never executes an instruction. There is no error message anywhere.
This changes the zero to mean what `Application.mk` intends by it.
## Impact
Affects any configuration that loads ELF programs (`CONFIG_ELF`) and runs an
application whose `Makefile` uses `PRIORITY = SCHED_PRIORITY_DEFAULT`. Those
programs currently never run; with this change they are created at
`SCHED_PRIORITY_DEFAULT` as intended.
No impact on programs that specify a numeric priority — those already worked
and
are unchanged. No API, ABI, build-system or configuration change.
Architecture
independent.
## Testing
**Host:** macOS 15 (darwin 25.5.0), `xtensa-esp32s3-elf-gcc` 12.2.
**Target:** ESP32-S3-DevKitC-1 with an ESP32-S3-WROOM-2 (N32R8V) module,
running a
`CONFIG_BUILD_KERNEL` configuration where `/system/bin/init` (NSH) and the
test
programs are separate ELF files in a ROMFS, loaded by `binfmt/elf`.
**Which programs are affected, confirmed by what each binary asks for:**
```
$ xtensa-esp32s3-elf-nm bin/ostest | grep nx_priority
00000000 A nx_priority <- PRIORITY = SCHED_PRIORITY_DEFAULT
$ xtensa-esp32s3-elf-nm bin/init | grep nx_priority
00000064 A nx_priority <- CONFIG_SYSTEM_NSH_PRIORITY=100
$ xtensa-esp32s3-elf-nm bin/getprime | grep nx_priority
00000032 A nx_priority <- CONFIG_TESTING_GETPRIME_PRIORITY=50
```
**Before.** `ostest` loads and then produces no output at all; the shell
never
returns. Programs with numeric priorities are unaffected and run normally.
```
nsh> /system/bin/ostest
load_absmodule: Successfully loaded module /system/bin/ostest
binfmt_dumpmodule: entrypt: 0x42c0000c
binfmt_dumpmodule: stacksize: 8192
exec_module: Executing /system/bin/ostest
exec_module: Initialize the user heap (heapsize=1048576)
<nothing further>
```
Halted over JTAG (OpenOCD + `xtensa-esp32s3-elf-gdb`) and walked the
scheduler
state, sampled four times ~12 s apart — stable, not a transient:
```
running=Idle_Task [0:Idle_Task st=3] [1:lpwork st=5] [3:/system/bin/init
st=6] [4:/system/bin/ostest st=2]
```
state 3 = `TSTATE_TASK_RUNNING`, 2 = `TSTATE_TASK_READYTORUN`. Walking
`g_readytorun` shows why:
```
===== g_readytorun list =====
Idle_Task pid=0 prio=0 state=3
/system/bin/ostest pid=4 prio=0 state=2
```
`ostest` is correctly enqueued, at priority 0, behind the idle task.
**After.** Same board, same image apart from this patch:
```
nsh> /system/bin/ostest
...
user_main: Exiting
ostest_main: Exiting with status 0
nsh> free
total used free maxused maxfree nused nfree name
379640 18744 360896 105648 353800 79 4 Kmem
4194304 1245184 2949120 2949120 Page
```
`ostest` runs to completion with status 0, and the page pool returns to its
baseline.
**Regression check on the same target**, all unchanged by this patch:
`getprime`
(priority 50) runs and reports the same result and timing; NSH (priority 100)
starts and remains interactive; `ps` shows no zombies after repeated runs.
`./tools/checkpatch.sh -f binfmt/elf.c` passes.
--
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]
