Skip to content

[7.5/10] arch/arm: Build a loadable module and a shared library as FDPIC too. - #20360

Merged
acassis merged 1 commit into
apache:masterfrom
casaroli:fdpic-module-flags
Sep 25, 2026
Merged

acassis merged 1 commit into
apache:masterfrom
casaroli:fdpic-module-flags

Conversation

@casaroli

Copy link
Copy Markdown
Contributor

Summary

Part of the FDPIC series. [5.5/10] #19940 taught the ELF module path what an FDPIC object is, so an application built as a module gets -mfdpic -fPIC and the arm-uclinuxfdpiceabi linker, and comes out a shared object the loader can bind.

The loadable module path was left behind. apps/Application.mk reaches it with DYNLIB = y, apps/Library.mk builds every shared library with it, and it is still a -r partial link with the stock linker. Such an object has no dynamic section, so nothing can bind an import to it, and there is no way to build a library an FDPIC module can call.

So CMODULEFLAGS and CXXMODULEFLAGS gain the same compiler flags, and LDMODULEFLAGS links a shared object rather than a partial one. The entry point stays with the caller, because a module is entered at _start while a library is only ever called into.

CXXMODULEFLAGS is defined here for the first time. apps/Library.mk compiles every C++ source of a shared library with it and no architecture ever defined it, so those sources were compiled with no architecture flags at all.

apache/nuttx-apps#3762 is the first user: its module fixtures stop hand-rolling the link and use these variables.

Impact

Everything else is under CONFIG_FDPIC, which defaults off and is selectable only where ARCH_HAVE_ELF_FDPIC is set.

CXXMODULEFLAGS replaces nothing, since it was empty.

Testing

Compiled and linked a library with the variables this patch produces, taken from a pimoroni-pico-2-plus tree configured with CONFIG_FDPIC:

$ arm-uclinuxfdpiceabi-readelf -dh libcounter.so
  OS/ABI:      ARM FDPIC
  Type:        DYN (Shared object file)
  Entry point: 0x0
  0x0e (SONAME)  Library soname: [libcounter.so]

Two PT_LOAD segments, R E and RW, as an FDPIC object needs.

tools/checkpatch.sh -c -u -m -g passes.

@github-actions github-actions Bot added Arch: arm Issues related to ARM (32-bit) architecture Size: S The size of the change in this PR is small labels Sep 25, 2026
CONFIG_FDPIC teaches the ELF module path what an FDPIC object is, so an
application built as a module gets -mfdpic -fPIC and the
arm-uclinuxfdpiceabi linker.  The loadable module path, which apps builds
with DYNLIB = y and which apps/Library.mk uses for a shared library, was
left as it was: a -r partial link with the stock linker.  That leaves an
object with no dynamic section, so the loader has nothing to bind an import
to, and there is no way to build a library an FDPIC module can call.

Give that path the same treatment.  CMODULEFLAGS and CXXMODULEFLAGS gain the
FDPIC compiler flags, and LDMODULEFLAGS links a shared object rather than a
partial one.  The entry point is left to the caller, because a module is
entered at _start while a library is only ever called into.

CXXMODULEFLAGS is also defined for the first time.  apps/Library.mk compiles
every C++ source of a shared library with it and no architecture defined it,
so those sources were compiled with no architecture flags at all.

Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
@github-actions

Copy link
Copy Markdown

MemBrowse Memory Report

No memory changes detected for:

@acassis
acassis merged commit 5513029 into apache:master Sep 25, 2026
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Arch: arm Issues related to ARM (32-bit) architecture Size: S The size of the change in this PR is small

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants