Nathan,
I've created https://github.com/apache/nuttx/issues/18558
I'm also working on a PR to fixup all the STM32 .ld files (using an awk
script to automate changing ". = ALIGN(4); _ebss = ABSOLUTE(.);" in .ld
files to ". = ALIGN(8); _ebss = ABSOLUTE(.);").
On 3/17/26 16:17, Nathan Hartman wrote:
Hi Peter,
Replying inline below:
On Mon, Mar 16, 2026 at 3:18 PM Peter Barada <[email protected]>
wrote:
Nathan,
I see two ways to fix this(that cover a majority of the cases):
* Increase alignment in .ld files that specify symbol (_ebss in
stm32 variants) used to locate the idle stack
* Adjust asm() in start function that clears LR and calls
__start to forcibly align SP down(at least for stm variants)
I think updating the .ld files is cleaner, but that makes the PR
review a bit unweildy due to the sheer number of affected .ld
files (100+ in just the stm32 variants). Question is which
approach I should take in creating the PR?
Since there are a large number of .ld files that need to be checked
and possibly fixed, I think the best bet is to file an issue in the
issue tracker with a list of all the files to be checked. The files
themselves can be fixed individually or in small batches and the list
can be updated in the issue tracker as work progresses. By having an
issue filed, it's possible we could get some additional volunteers to
check and fix these. I will try to help too (though I have been
swamped with other work lately, so it may take a little time). I think
this is a better approach than trying to make one gigantic PR.
Looking further at the .ld files (stm32 variants in this case),
there are multiple copies of the same content(outside of
comments). At some point it may be worth merging together a bunch
of these duplicate linker files into a "family" - but that's a
different issue.
I have thought of this as well; some microcontroller part numbers may
be used in multiple boards and therefore the .ld files are probably
duplicates or near duplicates. I don't know how this should be
addressed. I have had different thoughts but they're not fully baked
yet; one thought is to try to control linking via Kconfig options and
have a script or C-coded program in tools/ that would generate a
linker file based on the selected options; but this approach would
probably come with numerous edge cases and there's the question of how
to force some customization. Another idea might be to move the .ld
files into the arch/ tree, but with a mechanism to allow a particular
board to have its own custom .ld file, overriding the one in arch/ if
present; but this could be a can of worms with problems such as the
wrong .ld file being used without any indication this occurred. More
thoughts on this would be appreciated...
Cheers,
Nathan
--
Peter Barada
[email protected]
