Aksal/nuttx-apps
1
0
Fork 1
mirror of https://github.com/apache/nuttx-apps.git synced 2026-10-09 23:15:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
nuttx-apps/examples/fdpicxip/modules/user.c

73 lines
2.8 KiB
C
Raw Normal View History

examples/fdpicxip: Demonstrate FDPIC modules executed in place. The FDPIC counterpart of examples/nxflatxip, kept separate from it: that example is about NXFLAT, and mixing the two module formats into one program would leave neither demonstrating anything clearly. Four subcommands, each showing one property of the loader. 'qsort' is the simplest case it has -- one self-contained module, two concurrent instances, one shared copy of the text in flash and a private copy of the data each, with the pin count showing the extent held in place while they run and released after. 'solib' adds a shared library, so two objects are mapped and each instance still gets its own copy of both objects' data. 'cxx' is the same in C++, which additionally requires global constructors to have run in dependency order before main. 'jmprel' is a module whose imports are all in DT_JMPREL rather than DT_REL. The modules are embedded as headers rather than built as part of the app: linking one needs arm-uclinuxfdpiceabi binutils, which the tree does not require, so the headers are committed and both this example and testing/fs/xipfs build with a plain toolchain. Their sources are in modules/, with a makefile that rebuilds every header from them on an explicit 'make regen NUTTX_DIR=...' and is never invoked by the application build. It drives nuttx/tools/fdpic and writes the headers this example needs alongside the ones testing/fs/xipfs needs, so one source tree serves both and the two cannot drift apart. CPU is cortex-m3 there deliberately: a v7-M module runs on the v8-M targets too, so one set of blobs serves both the RP2350 and mps2-an500, while a cortex-m33 build produces blobs the Cortex-M7 cannot execute at all. This demonstrates; it does not assert. The assertions are in the fdpic and reject sections of apps/testing/fs/xipfs. Verified on a Pimoroni Pico Plus 2: all four subcommands, and nxflatxip unaffected alongside them. Also verified on mps2-an500 under QEMU, which is a Cortex-M7 -- a different core generation from the RP2350's Cortex-M33. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-07-30 13:40:04 +02:00
/****************************************************************************
* apps/examples/fdpicxip/modules/user.c
*
* SPDX-License-Identifier: Apache-2.0
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/
examples/fdpicxip, testing/fs/xipfs: A DT_NEEDED library is one instance. Both the demo and the test asserted that each running instance of a module gets its own copy of a library named in DT_NEEDED: two instances adding their own seed each saw a total of seed*3. That was true of the loader that walked DT_NEEDED itself. The loader now hands the work to dlopen(), which returns the object already in the module registry rather than loading a second copy of it, so there is one library and one set of its globals, shared by every module that names it. The module's own data stays private per instance, because exec() loads the module afresh each time. What an instance can still assert on its own is that every add it made landed in the library, so that is what it checks; the totals interleave and the final one counts both. The test additionally checks the consequences: the library is pinned once rather than once per instance, and its destructor runs once, at the last close, holding what both instances built up. USER_FAIL_PRIVATE becomes USER_FAIL_SHARED rather than gaining a companion. The bit is a private protocol between cxxuser.cpp, which sets it, and testing/fs/xipfs, which reads it; nothing else names it, and the property it used to report no longer exists. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-04 09:42:33 +02:00
/* Uses libcounter.so. Two instances run concurrently, and there is one
* library between them: DT_NEEDED is loaded with dlopen(), which returns
* the object already in the registry rather than a second copy of it, so
* the totals interleave and the final one counts both instances' bumps.
* What each instance can assert on its own is that every bump it made
* landed somewhere it can still see.
examples/fdpicxip: Demonstrate FDPIC modules executed in place. The FDPIC counterpart of examples/nxflatxip, kept separate from it: that example is about NXFLAT, and mixing the two module formats into one program would leave neither demonstrating anything clearly. Four subcommands, each showing one property of the loader. 'qsort' is the simplest case it has -- one self-contained module, two concurrent instances, one shared copy of the text in flash and a private copy of the data each, with the pin count showing the extent held in place while they run and released after. 'solib' adds a shared library, so two objects are mapped and each instance still gets its own copy of both objects' data. 'cxx' is the same in C++, which additionally requires global constructors to have run in dependency order before main. 'jmprel' is a module whose imports are all in DT_JMPREL rather than DT_REL. The modules are embedded as headers rather than built as part of the app: linking one needs arm-uclinuxfdpiceabi binutils, which the tree does not require, so the headers are committed and both this example and testing/fs/xipfs build with a plain toolchain. Their sources are in modules/, with a makefile that rebuilds every header from them on an explicit 'make regen NUTTX_DIR=...' and is never invoked by the application build. It drives nuttx/tools/fdpic and writes the headers this example needs alongside the ones testing/fs/xipfs needs, so one source tree serves both and the two cannot drift apart. CPU is cortex-m3 there deliberately: a v7-M module runs on the v8-M targets too, so one set of blobs serves both the RP2350 and mps2-an500, while a cortex-m33 build produces blobs the Cortex-M7 cannot execute at all. This demonstrates; it does not assert. The assertions are in the fdpic and reject sections of apps/testing/fs/xipfs. Verified on a Pimoroni Pico Plus 2: all four subcommands, and nxflatxip unaffected alongside them. Also verified on mps2-an500 under QEMU, which is a Cortex-M7 -- a different core generation from the RP2350's Cortex-M33. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-07-30 13:40:04 +02:00
*
* libcounter is also a *leaf* library -- it calls nothing outside itself,
* so it has no PLT and therefore no DT_PLTGOT. The loader has to fall back
* to PT_DYNAMIC vaddr + memsz to find its GOT. If that fallback is wrong
* the library cannot reach its own globals, which is exactly what the total
* below would expose.
*/
/****************************************************************************
* Included Files
****************************************************************************/
#include <stdlib.h>
#include <syslog.h>
#include <unistd.h>
/****************************************************************************
* Public Functions
****************************************************************************/
extern int counter_bump(int by);
extern int counter_total(void);
int main(int argc, char *argv[])
{
int seed = (argc > 1) ? atoi(argv[1]) : 0;
int i;
for (i = 0; i < 3; i++)
{
counter_bump(seed);
usleep(100000);
}
examples/fdpicxip, testing/fs/xipfs: A DT_NEEDED library is one instance. Both the demo and the test asserted that each running instance of a module gets its own copy of a library named in DT_NEEDED: two instances adding their own seed each saw a total of seed*3. That was true of the loader that walked DT_NEEDED itself. The loader now hands the work to dlopen(), which returns the object already in the module registry rather than loading a second copy of it, so there is one library and one set of its globals, shared by every module that names it. The module's own data stays private per instance, because exec() loads the module afresh each time. What an instance can still assert on its own is that every add it made landed in the library, so that is what it checks; the totals interleave and the final one counts both. The test additionally checks the consequences: the library is pinned once rather than once per instance, and its destructor runs once, at the last close, holding what both instances built up. USER_FAIL_PRIVATE becomes USER_FAIL_SHARED rather than gaining a companion. The bit is a private protocol between cxxuser.cpp, which sets it, and testing/fs/xipfs, which reads it; nothing else names it, and the property it used to report no longer exists. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-04 09:42:33 +02:00
syslog(LOG_INFO, "[user %d] library total = %d (at least %d) -- %s\n",
examples/fdpicxip: Demonstrate FDPIC modules executed in place. The FDPIC counterpart of examples/nxflatxip, kept separate from it: that example is about NXFLAT, and mixing the two module formats into one program would leave neither demonstrating anything clearly. Four subcommands, each showing one property of the loader. 'qsort' is the simplest case it has -- one self-contained module, two concurrent instances, one shared copy of the text in flash and a private copy of the data each, with the pin count showing the extent held in place while they run and released after. 'solib' adds a shared library, so two objects are mapped and each instance still gets its own copy of both objects' data. 'cxx' is the same in C++, which additionally requires global constructors to have run in dependency order before main. 'jmprel' is a module whose imports are all in DT_JMPREL rather than DT_REL. The modules are embedded as headers rather than built as part of the app: linking one needs arm-uclinuxfdpiceabi binutils, which the tree does not require, so the headers are committed and both this example and testing/fs/xipfs build with a plain toolchain. Their sources are in modules/, with a makefile that rebuilds every header from them on an explicit 'make regen NUTTX_DIR=...' and is never invoked by the application build. It drives nuttx/tools/fdpic and writes the headers this example needs alongside the ones testing/fs/xipfs needs, so one source tree serves both and the two cannot drift apart. CPU is cortex-m3 there deliberately: a v7-M module runs on the v8-M targets too, so one set of blobs serves both the RP2350 and mps2-an500, while a cortex-m33 build produces blobs the Cortex-M7 cannot execute at all. This demonstrates; it does not assert. The assertions are in the fdpic and reject sections of apps/testing/fs/xipfs. Verified on a Pimoroni Pico Plus 2: all four subcommands, and nxflatxip unaffected alongside them. Also verified on mps2-an500 under QEMU, which is a Cortex-M7 -- a different core generation from the RP2350's Cortex-M33. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-07-30 13:40:04 +02:00
seed, counter_total(), seed * 3,
examples/fdpicxip, testing/fs/xipfs: A DT_NEEDED library is one instance. Both the demo and the test asserted that each running instance of a module gets its own copy of a library named in DT_NEEDED: two instances adding their own seed each saw a total of seed*3. That was true of the loader that walked DT_NEEDED itself. The loader now hands the work to dlopen(), which returns the object already in the module registry rather than loading a second copy of it, so there is one library and one set of its globals, shared by every module that names it. The module's own data stays private per instance, because exec() loads the module afresh each time. What an instance can still assert on its own is that every add it made landed in the library, so that is what it checks; the totals interleave and the final one counts both. The test additionally checks the consequences: the library is pinned once rather than once per instance, and its destructor runs once, at the last close, holding what both instances built up. USER_FAIL_PRIVATE becomes USER_FAIL_SHARED rather than gaining a companion. The bit is a private protocol between cxxuser.cpp, which sets it, and testing/fs/xipfs, which reads it; nothing else names it, and the property it used to report no longer exists. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-04 09:42:33 +02:00
counter_total() >= seed * 3 ? "PASS" : "FAIL");
examples/fdpicxip: Demonstrate FDPIC modules executed in place. The FDPIC counterpart of examples/nxflatxip, kept separate from it: that example is about NXFLAT, and mixing the two module formats into one program would leave neither demonstrating anything clearly. Four subcommands, each showing one property of the loader. 'qsort' is the simplest case it has -- one self-contained module, two concurrent instances, one shared copy of the text in flash and a private copy of the data each, with the pin count showing the extent held in place while they run and released after. 'solib' adds a shared library, so two objects are mapped and each instance still gets its own copy of both objects' data. 'cxx' is the same in C++, which additionally requires global constructors to have run in dependency order before main. 'jmprel' is a module whose imports are all in DT_JMPREL rather than DT_REL. The modules are embedded as headers rather than built as part of the app: linking one needs arm-uclinuxfdpiceabi binutils, which the tree does not require, so the headers are committed and both this example and testing/fs/xipfs build with a plain toolchain. Their sources are in modules/, with a makefile that rebuilds every header from them on an explicit 'make regen NUTTX_DIR=...' and is never invoked by the application build. It drives nuttx/tools/fdpic and writes the headers this example needs alongside the ones testing/fs/xipfs needs, so one source tree serves both and the two cannot drift apart. CPU is cortex-m3 there deliberately: a v7-M module runs on the v8-M targets too, so one set of blobs serves both the RP2350 and mps2-an500, while a cortex-m33 build produces blobs the Cortex-M7 cannot execute at all. This demonstrates; it does not assert. The assertions are in the fdpic and reject sections of apps/testing/fs/xipfs. Verified on a Pimoroni Pico Plus 2: all four subcommands, and nxflatxip unaffected alongside them. Also verified on mps2-an500 under QEMU, which is a Cortex-M7 -- a different core generation from the RP2350's Cortex-M33. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-07-30 13:40:04 +02:00
/* Reported through the exit status as well as the log, so a test can
* assert on it rather than a human reading the console.
*/
examples/fdpicxip, testing/fs/xipfs: A DT_NEEDED library is one instance. Both the demo and the test asserted that each running instance of a module gets its own copy of a library named in DT_NEEDED: two instances adding their own seed each saw a total of seed*3. That was true of the loader that walked DT_NEEDED itself. The loader now hands the work to dlopen(), which returns the object already in the module registry rather than loading a second copy of it, so there is one library and one set of its globals, shared by every module that names it. The module's own data stays private per instance, because exec() loads the module afresh each time. What an instance can still assert on its own is that every add it made landed in the library, so that is what it checks; the totals interleave and the final one counts both. The test additionally checks the consequences: the library is pinned once rather than once per instance, and its destructor runs once, at the last close, holding what both instances built up. USER_FAIL_PRIVATE becomes USER_FAIL_SHARED rather than gaining a companion. The bit is a private protocol between cxxuser.cpp, which sets it, and testing/fs/xipfs, which reads it; nothing else names it, and the property it used to report no longer exists. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-04 09:42:33 +02:00
return counter_total() >= seed * 3 ? EXIT_SUCCESS : EXIT_FAILURE;
examples/fdpicxip: Demonstrate FDPIC modules executed in place. The FDPIC counterpart of examples/nxflatxip, kept separate from it: that example is about NXFLAT, and mixing the two module formats into one program would leave neither demonstrating anything clearly. Four subcommands, each showing one property of the loader. 'qsort' is the simplest case it has -- one self-contained module, two concurrent instances, one shared copy of the text in flash and a private copy of the data each, with the pin count showing the extent held in place while they run and released after. 'solib' adds a shared library, so two objects are mapped and each instance still gets its own copy of both objects' data. 'cxx' is the same in C++, which additionally requires global constructors to have run in dependency order before main. 'jmprel' is a module whose imports are all in DT_JMPREL rather than DT_REL. The modules are embedded as headers rather than built as part of the app: linking one needs arm-uclinuxfdpiceabi binutils, which the tree does not require, so the headers are committed and both this example and testing/fs/xipfs build with a plain toolchain. Their sources are in modules/, with a makefile that rebuilds every header from them on an explicit 'make regen NUTTX_DIR=...' and is never invoked by the application build. It drives nuttx/tools/fdpic and writes the headers this example needs alongside the ones testing/fs/xipfs needs, so one source tree serves both and the two cannot drift apart. CPU is cortex-m3 there deliberately: a v7-M module runs on the v8-M targets too, so one set of blobs serves both the RP2350 and mps2-an500, while a cortex-m33 build produces blobs the Cortex-M7 cannot execute at all. This demonstrates; it does not assert. The assertions are in the fdpic and reject sections of apps/testing/fs/xipfs. Verified on a Pimoroni Pico Plus 2: all four subcommands, and nxflatxip unaffected alongside them. Also verified on mps2-an500 under QEMU, which is a Cortex-M7 -- a different core generation from the RP2350's Cortex-M33. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-07-30 13:40:04 +02:00
}
Reference in a new issue Copy permalink