Hi KR, I submitted the fix: https://github.com/apache/nuttx/pull/20419
This issue was found during the NuttX port to the CDP1802 (a very special processor from 1976 that is still in production) BR, Alan On Thu, Oct 1, 2026 at 2:41 AM <[email protected]> wrote: > Hi, yes, I encountered the same thing in timer code when making the > initial port of AVR DA/DB and there are probably more cases where there > is something subtly broken by the assumption that int is 32 bit and > atomic. (I mentioned struct circbuf_s before but still did not have the > time to figure out a non-intrusive fix.) > > Thanks for the fix here. > > On 2026-09-30 21:51, Alan C. Assis wrote: > > I submitted a fix: > > > > https://github.com/apache/nuttx/pull/20419 > > > > On Wed, Sep 30, 2026 at 9:28 AM Alan C. Assis <[email protected]> > > wrote: > > > >> 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 > >>> > >> >
