hitHuang opened a new pull request, #19438:
URL: https://github.com/apache/nuttx/pull/19438

   ## Summary
   
   `host_flags_to_mode()` in `arch/arm64/src/common/arm64_hostfs.c`,
   `arch/arm/src/common/arm_hostfs.c`, and 
`arch/risc-v/src/common/riscv_hostfs.c`
   (identical code in all three) used a trailing `0` entry in `modeflags[]` as 
the
   loop-termination sentinel when translating a POSIX `open()` flags value to 
the ARM
   semihosting `SYS_OPEN` mode index.
   
   `O_RDONLY` is defined as `0` and is exactly `modeflags[1]`. Since the loop 
terminated
   as soon as it saw a `0` entry, it stopped one iteration too early and never 
got to
   compare that entry, so a bare `O_RDONLY` open always fell through to 
`-EINVAL`.
   
   This breaks every semihosting-hostfs `open()` done with plain `O_RDONLY` — 
which is
   exactly what the ELF loader (`libelf_initialize()`) uses to open 
executables. Any
   `knsh`-style config that boots an init binary via semihosting hostfs hits a 
fatal
   `DEBUGASSERT(ret > 0)` in `sched/init/nx_bringup.c` right after
   `load_absmodule: Loading /system/bin/init`, on every boot.
   
   Fixed by bounding the loop by array size (`nitems()`) instead of a value 
sentinel,
   and dropping the now-unneeded trailing `0` entry.
   
   ## Impact
   
   - Affects any board using `CONFIG_{ARM,ARM64,RISCV}_SEMIHOSTING_HOSTFS` to 
open a file
     with a bare `O_RDONLY` flag (no `O_TEXT`/`O_CREAT`/etc), most notably ELF 
binfmt
     loading a program from a semihosting-mounted hostfs.
   - No Kconfig, API, or build system changes. Pure bugfix, no behavior change 
for any
     other flag combination.
   
   ## Testing
   
   Verified on QEMU across all three affected architectures.
   
   ### rv-virt:knsh (default config)
   
   Before fix — boot hangs with a fatal assertion:
   
   ```
   ABC[    0.032000] dump_assert_info: Current Version: NuttX  13.0.0 
20579ab531-dirty Jul 15 2026 09:46:15 risc-v
   [    0.032000] dump_assert_info: Assertion failed : at file: 
init/nx_bringup.c:389 task: AppBringUp process: Kernel 0x80201d04
   [    0.032000] up_dump_register: EPC: 80214720
   [    0.032000] up_dump_register: A0: 80607860 A1: 00000000 A2: 00000000 A3: 
0000007e
   [    0.032000] up_dump_register: A4: 00000002 A5: 00000008 A6: 0000002e A7: 
00000001
   [    0.032000] up_dump_register: T0: 00000000 T1: 00000000 T2: 00000000 T3: 
00000000
   [    0.032000] up_dump_register: T4: 00000000 T5: 00000000 T6: 00000000
   [    0.032000] up_dump_register: S0: fffffffb S1: 00000000 S2: 8021b5ac S3: 
00042022
   [    0.032000] up_dump_register: S4: 80608000 S5: 80608000 S6: 80608000 S7: 
00000006
   [    0.032000] up_dump_register: S8: 00000185 S9: 80608e10 S10: 00000000 
S11: 00000000
   [    0.032000] up_dump_register: SP: 8060c6b0 FP: fffffffb TP: 00000000 RA: 
80214720
   [    0.032000] dump_stackinfo: User Stack:
   [    0.032000] dump_stackinfo:   base: 0x8060c040
   [    0.032000] dump_stackinfo:   size: 00001984
   [    0.032000] dump_stackinfo:     sp: 0x8060c6b0
   [    0.032000] stack_dump: 0x8060c690: 80608e10 00000000 8021dff4 00042022 
80606000 8021c5f4 8060c6b0 80214908
   [    0.032000] stack_dump: 0x8060c6b0: 80201d04 00000000 00000000 00000000 
00000000 00000000 00000000 00000000
   [    0.032000] stack_dump: 0x8060c6d0: 00000000 00000000 80608e10 80607860 
00000000 8021b5ac 00000185 7474754e
   [    0.032000] stack_dump: 0x8060c6f0: 00000058 00000000 00000000 00000000 
00000000 00000000 00000000 00000000
   [    0.032000] stack_dump: 0x8060c710: 00000000 00000000 00000000 00000000 
2e333100 00302e30 fffffffb 00000000
   [    0.032000] stack_dump: 0x8060c730: 00000000 30320000 61393735 31333562 
7269642d 4a207974 31206c75 30322035
   [    0.032000] stack_dump: 0x8060c750: 30203632 36343a39 0035313a 8020990a 
00000000 00000000 73697200 00762d63
   [    0.032000] stack_dump: 0x8060c770: 8060c7d0 80609078 fffffffb 802139f4 
00000000 00000000 00000000 00000000
   [    0.032000] stack_dump: 0x8060c790: 00000000 00000000 00000000 00000000 
00000000 00000064 fffffffb 8020785c
   [    0.032000] stack_dump: 0x8060c7b0: 00000000 00000064 00000c00 80201d64 
00000000 00000000 00000000 00000000
   [    0.032000] stack_dump: 0x8060c7d0: 00026400 00000000 00000000 00000c00 
00000000 80608e10 00000002 80202820
   [    0.032000] stack_dump: 0x8060c7f0: 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000
   [    0.032000] dump_tasks:    PID GROUP PRI POLICY   TYPE    NPX STATE   
EVENT      SIGMASK          STACKBASE  STACKSIZE   COMMAND
   [    0.032000] dump_tasks:   ----   --- --- -------- ------- --- ------- 
---------- ---------------- 0x80606000      2048   irq
   [    0.032000] dump_task:       0     0   0 FIFO     Kthread -   Ready       
       0000000000000000 0x80607b40      3040   Idle_Task
   [    0.032000] dump_task:       1     0 100 RR       Kthread -   Ready       
       0000000000000000 0x8060a050      1968   lpwork 0x80600010 0x80600060
   [    0.032000] dump_task:       2     0 240 RR       Kthread -   Running     
       0000000000000000 0x8060c040      1984   AppBringUp
   ```
   
   Same failure reproduced on `qemu-armv7a:knsh` and `qemu-armv8a:knsh`.
   
   After fix — boots cleanly to NSH:
   
   ```
   ABC
   NuttShell (NSH) NuttX-13.0.0
   nsh>
   nsh> ps
     TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK        
    STACK COMMAND
       0     0     0   0 FIFO     Kthread   - Ready              
0000000000000000 0003040 Idle_Task
       1     0     0 100 RR       Kthread   - Waiting  Semaphore 
0000000000000000 0001968 lpwork 0x80600010 0x80600060
       3     3     0 100 RR       Task      - Running            
0000000000000000 0003008 /system/bin/init
   nsh> uname -a
   NuttX 13.0.0 e4c66d6c4f-dirty Jul 15 2026 09:50:54 risc-v rv-virt
   ```
   
   Confirmed the same fix resolves boot on `qemu-armv7a:knsh` and 
`qemu-armv8a:knsh` as well.


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