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
