building position independent executable using newlib

[Massimiliano Cialdi]

Hi all,

I'm using newlib-nano as embedded in the arm-none-eabi toolchain, and I’m
trying to build a position-independent executable for an embedded target.

This executable is monolithic and fully standalone. It does not call any
external function, and no external entity will try to call its functions.
I wrote a custom loader/relocator that takes as input a raw binary (not an
ELF file) and some metadata (section offsets/sizes and the entry point).
The binary is built with -fPIE and linked with -pie.

The GCC manual says about -pie:

  Produce a dynamically linked position independent executable on
  targets that support it. For predictable results, you must also
  specify the same set of options used for compilation (-fpie, -fPIE,
  or model suboptions) when you specify this linker option.

I can guarantee that all of *my* object files are compiled with -fPIE.
But what about newlib? Do I need to rebuild newlib with -fPIE to be safe?

Right now it seems to work, but I wonder if I'm just getting lucky.

I'm only using a few functions from newlib: strlen, memcpy, memcmp,
memset, strchr, strcspn, strncmp, strncpy, strrchr, strspn. I don’t use
any function that requires dynamic allocation, and I have no intention
to in the future.

Also, beyond newlib, there’s libgcc. For now I’m using functions like
__aeabi_uldivmod, __popcountsi2, __udivmoddi4, __aeabi_ldiv0 — but that’s
driven by the compiler.

So the big question is: in order to be safe and reliable, do I need to
rebuild the whole toolchain with -fPIE, just newlib, or can I ignore this
entire concern?

Thanks in advance for any clarification.

Best regards
-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20250326/523d1ce3/attachment.htm>