genlink-cmsis.py may fail to generate includes for a vendor supplied linker script

[rhempel]

I'm working on trying CMRX for a simple blinky example for the MAX32690FTHR board. I am at the stage where the CMRX aware linker script has to be generated from the vendor supplied (CMSIS compatible?) linker script.

I have figured out the commands that the CMake system executes to create the modified linker script, and to add the correct libraries to the include files. For example, if I'm making an STM32H7 compatible project, the CMake system would do something like:

python src/third_party/cmrx/ld/genlink-cmsis.py --create STM32H7A3ZI/linker_script.ld STM32H7A3ZI/foo_linker_script.ld foo python src/third_party/cmrx/ld/genlink-cmsis.py --add-application bar foo STM32H7A3ZI

I can confirm that the foo_linker_script.ld is modified to include the generated instance and other memory section includes as a result of the --create option

However, for the vendor supplied linker script for the MAX32690, the genlink-cmsis.py does not generate the correct includes :-(

I have attached the vendor supplied linker script for review ... remove the .txt suffix :-)

It's actually not too hard to figure out what is supposed to be changed in the includes - it might be easier to document what the Pythin script should do - or it might be a relatively simple fix to handle the max32690 file. I suspect that handling the general case of arbitrary .ld files might be more difficult than doing it manually :-)

max32690_rom.ld.txt

[ventZl]

Just to summarize and clarify:

Using the provided linker script, the genlink-cmsis.py will correctly process the --create option and generate modified linker script, but will fail to update linker script includes when --add-application is used later?

[rhempel]

No, the add-application correctly updates the individual generated include files, the max32690_rom.ld script should be modified with includes in the correct sections but the new generated script doesn't have all of the includes. In fact, if there is no RESET_HANDLER() defined, even the instance include does not get generated.

[ventZl]

Current linker script parser is kind-of experimental and is whitespace-aware. The reason for this is that the comparison of original and altered linker scripts is easy with whitespace retained. This aided the initial development of memory protection handling.

Naturally, different vendors place whitespace different in their linker scripts and thus the parser fails to parse some scripts.

This basically warrants a complete rewrite of linker script parsers to ignore whitespace, which is a right move. Doing so would allow us to parse it as AST or some other structure having some semantics in it rather than tokenizer which current parser is.

Another option would be to reindent the script to make it compatible with current parser but that would only extend the current pain.

[rhempel]

The challenge is going to be that user supplied linker scripts will be a little more difficult to check for diffs - so my input would be to create a pass-through mode where a user or vendor created linker script can be processed into a canonical CMRX compatible linker script.

Not sure if this is necessary, I'm just thinking about the difference between autogenerated vs modified vs original source.