Hi KR,
Another different topic here:
Could you please verify this issue that should affect AVR:
Several open() flags are defined as shifts past bit 15, for example
O_DIRECTORY (1U << 16), O_CLOEXEC (1U << 19) and O_NOFOLLOW (1U <<
17).
- Where int is 16 bits, these shifts are undefined. GCC turns every
one
of them
into 0.
- open() takes int oflags, so it can't carry those bits anyway.
- The compiler warning never appears, because NuttX includes its
headers
with
-isystem, which hides warnings from them.
The effect.
- opendir() never passed O_DIRECTORY, so opening /proc failed with
ENOENT and ps
broke.
- O_CLOEXEC and O_NOFOLLOW silently did nothing.
- AVR also has a 16-bit int, so it has the same latent bug.
If this issue exists on AVR, your system probably cannot mount /proc,
and
the ps command will not work.
BR,
Alan
On Mon, Sep 28, 2026 at 9:45 AM <[email protected]> wrote:
-1 (non-binding) for AVR DA/DB
Fails to compile with:
avr-ld: staging/libsched.a(sem_destroy.o): in function `.L3':
sem_destroy.c:(.text.nxsem_destroy+0x46): undefined reference to
`__atomic_load_4'
I tracked this down to a patch series that includes commit
4ca2256a9beef
(nuttx/atomic: select LIBC_ATOMIC_IRQ for archs without atomic
support)
- this commit did not cover AVR DA/DB.
I prepared a patch and uploaded it to my git repository nuttx.git at
git.kerogit.eu accessible through HTTP/S. (Trying to prevent bot
traffic
by not posting the URL in machine-readable form.) The relevant branch
is
called avrdx_fix_13.1. The patch is also attached to this message - I
don't have a GitHub account so, if possible, I would like to ask
someone
to open a PR and merge it to development branch. It's a simple
one-liner
doing the same thing as what the 4ca2256a9beef does, simply adds
"select
LIBC_ATOMIC_IRQ" to Kconfig. (If the vote for RC0 fails, please merge
it
to RC1 as well.)
With the patch, build process completes - for breadxavr:nsh
configuration:
Register: nsh
Register: sh
LD: nuttx
Memory region Used Size Region Size %age Used
flash: 56125 B 128 KB 42.82%
sram: 780 B 16 KB 4.76%
eeprom: 0 B 512 B 0.00%
rodata: 602 B 4 KB 14.70%
(Compared to previous version 13.0, the binary size increased by 850
bytes. Most of that is caused by changes in fs/inode starting with
patch
e73947e9e so not much can be done to alleviate that - at least not
easily.)
Other than that, there also seems to be a performance regression
observed when running a stress test app which is apparently dropping
bytes from UART (interrupt not serviced in time.) Takes few hours to
manifest though so I'll try to track that one down for 13.2.
On 2026-09-27 07:20, Alin Jerpelea wrote:
> Hello all,
> Apache NuttX 13.1.0 RC0 has been staged under [1] and it's
> time to vote on accepting it for release. Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> required to pass.
>
> The Apache requirements for approving a release can be found here [3]
> "Before voting +1 PMC members are required to download the signed
> source code package, compile it as provided, and test the resulting
> executable on their own platform, along with also verifying that the
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
>
> SCM Information:
> Release tag: nuttx-13.1.0-RC0
> Hash for the release nuttx tag:
> 2b5c0de5e933281c209f954a63b99cf10c132346
> Hash for the release nuttx-apps tag:
> 3c772ea35b9245972e18999828f7b533e6fc57cc
>
> [1] https://dist.apache.org/repos/dist/dev/nuttx/13.1.0-RC0/
> [2]
>
https://raw.githubusercontent.com/apache/nuttx/nuttx-13.1.0-RC0/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]
>
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
