Conversation
DT_REL and DT_JMPREL hold the link-time address of their table, and the loader read the table at that value as a file offset. The two are equal only when the segment that holds it starts at file offset 0. An object linked with its text at file offset 0x1000, as the tree's gnu-elf.ld does, had its relocations read from padding, so none were applied and the module called through unrelocated pointers. Translate the address through the PT_LOAD headers first. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
casaroli
added a commit
to casaroli/nuttx-apps
that referenced
this pull request
Sep 28, 2026
The fixtures were built by makefiles and scripts in nuttx/tools/fdpic. Review of apache/nuttx#19940 asked that NuttX not carry a module build of its own, so the build moves here, beside the sources it builds. They keep a build of their own because they are loader edge cases: a library with a SONAME, a module with more DT_NEEDED entries than the loader follows, one whose imports stay in the lazy binding table, and one naming a symbol the firmware does not export. Application.mk cannot say any of that. The build uses the configured tree's module flags (CMODULEFLAGS, CXXMODULEFLAGS, LDMODULEFLAGS), linker script and crt0 source. Three things are pinned instead, so that the committed headers do not depend on how the tree is configured: the CPU (cortex-m3, so one set of headers runs on both v7-M and v8-M), no debug information, and -Os. A library is compiled with default visibility, because the module flags hide every symbol and a library must export its functions. fdpic-embed.py becomes xxd and a template. fdpic-verify.sh and nuttx-exports.sh go with no replacement: they checked at build time what the xipfs suite already asserts at run time. The headers are regenerated, and the .fdpic suffix is gone: a module is named like any other module. A fixture now starts in the tree's crt0, which needs apache/nuttx#20388 to run its constructors, and the library fixtures need apache/nuttx#20368. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
github-actions
Bot
added
Arch: arm
|
| (*ctor)(); | ||
| call_initializer(*ctor); | ||
| } | ||
| } |
Contributor
There was a problem hiding this comment.
why not call fdpic_call or fdpic_invoke
Under FDPIC an .init_array or .fini_array entry is a code address, but a C function pointer is a function descriptor. crt0 called each entry through a function pointer, so it read the constructor's first instructions as a descriptor and jumped to garbage. Call each entry with fdpic_call() and the data base from fdpic_base(), which is the module's own. Without CONFIG_FDPIC both are a direct call, as before. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
casaroli
force-pushed
the
fdpic-fileoff-crt0
branch
from
September 29, 2026 08:46
8376df2 to
c894786
Compare
casaroli
added a commit
to casaroli/nuttx-apps
that referenced
this pull request
Sep 29, 2026
The fixtures were built by makefiles and scripts in nuttx/tools/fdpic. Review of apache/nuttx#19940 asked that NuttX not carry a module build of its own, so the build moves here, beside the sources it builds. They keep a build of their own because they are loader edge cases: a library with a SONAME, a module with more DT_NEEDED entries than the loader follows, one whose imports stay in the lazy binding table, and one naming a symbol the firmware does not export. Application.mk cannot say any of that. The build uses the configured tree's module flags (CMODULEFLAGS, CXXMODULEFLAGS, LDMODULEFLAGS), linker script and crt0 source. Three things are pinned instead, so that the committed headers do not depend on how the tree is configured: the CPU (cortex-m3, so one set of headers runs on both v7-M and v8-M), no debug information, and -Os. A library is compiled with default visibility, because the module flags hide every symbol and a library must export its functions. fdpic-embed.py becomes xxd and a template. fdpic-verify.sh and nuttx-exports.sh go with no replacement: they checked at build time what the xipfs suite already asserts at run time. The headers are regenerated, and the .fdpic suffix is gone: a module is named like any other module. A fixture now starts in the tree's crt0, which needs apache/nuttx#20388 to run its constructors, and the library fixtures need apache/nuttx#20368. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Part of the FDPIC series. Two bugs stop an FDPIC module from starting when it is linked the way the tree's own module flags link it (
CMODULEFLAGS,LDMODULEFLAGS,gnu-elf.ld): its text starts at file offset 0x1000, and it carries the tree'scrt0. The modules the xipfs tests carry today are linked differently and do not hit either one.DT_RELandDT_JMPRELhold the link-time address of their table, and the loader read the table at that value as a file offset. The two are equal only when the segment starts at file offset 0. Otherwise the relocations were read from padding and none were applied, so_startcalledmain()through an unrelocated pointer. The address is now translated through thePT_LOADheaders first.Under FDPIC an
.init_arrayentry is a code address, but a C function pointer is a descriptor.crt0called each entry through a function pointer, so withCONFIG_HAVE_CXXINITIALIZEit read a constructor's first instructions as a descriptor. It now calls each entry withfdpic_call()and the module's own data base fromfdpic_base().Impact
Only FDPIC modules change. An object whose segments start at file offset 0 translates to the same offset as before, and without
CONFIG_FDPICcrt0makes the same direct call as before.Testing
mps2-an500:xipfswithCONFIG_FDPICunder QEMU,xipfs_test fdpic, with the module fixtures rebuilt by the tree's module flags (apache/nuttx-apps#3762):funcdescWith the fixtures on apps master the result is unchanged by this PR.
qemu-armv7a:knshbuilds with-Werror, includingmake export(which buildscrt0.o) and the apps import.tools/checkpatch.sh -c -u -m -gpasses.