The asker has two bare-metal ELF images that will be co-resident in physical memory and wants them to share a region containing both data and code. Their instinct is to drop my_object_file.o(.data) into a fixed-address section (.my_section 0x10000) in both linker scripts and hope the resulting symbols line up.

Why it's tricky: two independent link invocations are exactly that — independent. Even with the same object file and the same address, the linker is free to:

• Order symbols differently within the section (especially if other inputs contribute).
• Apply different relocations because the surrounding code references symbols at different addresses.
• Inline, fold (ICF), or garbage-collect (--gc-sections) entries that look unused from one ELF's perspective but not the other's.
• Generate PLT/GOT stubs in one image and not the other.

So "include the same .o in the same fixed section" is necessary but not sufficient. You need the addresses, not the inputs, to be the contract between the two ELFs.

A more robust approach:

• Single source of truth for layout. Build the shared region as its own ELF (or a flat binary) linked once at 0x10000. Generate a symbol file from it (nm or --just-symbols).
• Consume symbols, not sources. In each of the two application linker scripts, pull in those addresses via INCLUDE shared.syms or pass -Wl,--just-symbols=shared.elf. Now both ELFs reference identical absolute addresses without re-linking the shared code.
• Alternatively, hardcode the contract: declare each shared symbol with PROVIDE(my_func = 0x10010); in both scripts. Ugly, but explicit.
• Mark the section NOLOAD in one of the ELFs if only the other should actually deposit bytes there — otherwise both loaders will write the region and the second write wins.

Gotchas:

• Code sharing is harder than data. Shared functions must be position-independent or linked at the exact address they'll execute from. Any internal calls/branches resolve at link time, so both ELFs must agree on those targets — which is exactly what --just-symbols from a pre-linked shared image gives you.
• BSS-style zero-init in a shared region is dangerous: whichever ELF's startup runs second will clobber state the first one set up.
• Cache coherency and MPU/MMU regions matter on real silicon — the shared window typically needs to be mapped as shareable (or uncached) on both cores/contexts.
• Don't trust --gc-sections here; mark the shared section with KEEP(...).