Re: [PING]: [PATCH] ld: Account for .tbss size on ARM EABI targets

On Tue, Sep 01, 2026 at 10:28:06AM +0200, Torbjorn SVENSSON wrote:
> Please consider this simplified version of the linker script that we use
> for our STM32F407VG device that we manufacture.
> 
> MEMORY
> {
>   FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
>   RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 128K
> }
> 
> SECTIONS
> {
>   .text :
>   {
>     *(.text)
>     ...
>   } >FLASH
> 
>   _sidata = LOADADDR(.data);
>   .data : ALIGN(4)
>   {
>     _sdata = .;
>     *(.data)
>     ...
>     _edata = .;
>   } >RAM AT> FLASH
> 
>   _sitdata = LOADADDR(.tdata);
>   .tdata : ALIGN(4)
>   {
>     _stdata = .;
>     *(.tdata)
>     ...
>     _etdata = .;
>   } >RAM AT> FLASH
> 
>   .tbss (NOLOAD) : ALIGN(4)
>   {
>     _stbss = .;
>     *(.tbss)
>     ...
>     _etbss = .;
>   } >RAM
> 
>   .bss (NOLOAD) : ALIGN(4)
>   {
>     _sbss = .;
>     *(.bss)
>     ...
>     _ebss = .;
>   } >RAM
> }
> 
> As you can see, we have a pristine copy of .tdata in FLASH and another
> copy in RAM that the program is working on. Whenever there would be a
> second thread, the data would be copied from flash again and that
> would ensure that the initial values are correct.
> There needs to be no special treatment for .tbss, since the only thing
> required are the lengths (to know how much RAM to clear).
> 
> > 
> > I doubt very much your target systems are running out of flash for
> > very long.  Even back when I was designing hardware, support chips in
> > the mid 80s were starting to provide RAM shadowing of ROM.  The system
> > only ran out of ROM until it was copied to RAM, at which point the RAM
> > shadow took over.  ROM was *much* slower, not only due to a slower
> > access time but also due to the support chips allowing it to be 8-bit
> > memory when main memory was 32-bit.  I haven't been in the hardware
> > game for a long time, but I expect the speed difference between ROM
> > and RAM still holds.  Which means you wouldn't want to access ROM for
> > a pristine copy of .tdata when setting up the second thread (and you
> > might not even be able to access ROM again without a reboot).
> 
> In the Arm Cortex-M world, there are speed differences between RAM and
> ROM, just like you explain, but the pipeline limits the impact of it.
> RAM is far more expensive than FLASH(ROM). As you can see in the linker
> script above, flash is about 10 times bigger than RAM. To allow the
> entire application to fit in RAM, plus the working data itself, then,
> RAM would always need to be bigger than FLASH. Building such a device
> would be possible, but very expensive.

OK, wrong assumption on my part.  I haven't worked as an electronics
engineer for a very long time..

So back to your patch, which is starting to make more sense.  I could
take the position that your script can be modified to force .tbss to
occupy space.  That's just a matter of setting the .bss start vma with
something like:

   .bss ALIGN (ADDR (.tbss) + SIZEOF (.tbss), 4) (NOLOAD) :

As far as script vma tweaks go it's not too horrible, cf. .branch_lt
in emulparams/elf64ppc.sh.  This should only fail if there happens to
be an orphan section inserted between .tbss and .bss.  (You'd need a
.tbss style section that didn't match any of the input section
wildcards in .tbss, so very unlikely.)  Doing it this way also has the
benefit that it should work with any version of GNU ld.

On the other hand, this variation of TLS might be generally useful in
embedded systems.  So if you want to go ahead with your patch I'd like
to see tls_nobits_occupies_vma set from ${EMBEDDED} rather than a
target test.  This will mean you are probably better off modifying
tls-app.d to allow both sets of numbers rather than specifying all the
target triples that have targ_emul=armelf to use tls-app-eabi.d.
While you're at that, replace the ".word	0x000080bc" and
similar with ".*".

-- 
Alan Modra