PrgCode section name

[flit]

Separate sections for read-only and read-write are needed by pyocd's conversion script and generally good to have split out since the ELF section attributes are quite different. These section names match the names used in Keil µVision generated FLM files, and thus are more compatible. (Otherwise, I'd have used the standard names; I'm not particularly fond of PrgCode and PrgData.)

And yes, there are two PrgData sections, but with different ELF attributes.

[AsafFisher]

Why did you rename the program .text segmemt to PrgCode ?
Keil µVision is an IDE. Why do names that are made by a specific IDE vendor are more compatible?

[Tiwalun]

This would also make it compatible with the target-gen tool in probe-rs, which can generate the target description file for probe-rs automatically.

[flit]

FLM algos use PrgCode and PrgData as the section names. I don't think I've seen an FLM in a CMSIS-Pack that doesn't follow this. The FLM standard basically implies this is required by way of only describing how to create a flash algo using the Keil tools and armlink.

Even if PrgCode/PrgData aren't used, there needs to be .data and .bss sections and not all in .text. I can modify pyocd's algo generator script to deal with that. Not sure about other tools.

[flit]

@Tiwalun

This would also make it compatible with the target-gen tool in probe-rs

Do you mean PrgCode/PrgData makes it incompatible, or the use of a single .text section.

[flit]

You can see the the template .FLM sources in the CMSIS_5 repo that these sections are used: https://github.com/ARM-software/CMSIS_5/blob/develop/Device/_Template_Flash/Target.lin

[Tiwalun]

Do you mean PrgCode/PrgData makes it incompatible, or the use of a single .text section.

The tool also expects PrgCode/PrgData, so changing the sections would improve compability.

[Dirbaio]

Even with this change, all memory accesses are still done PC-relative. This means that you still can't change the location of .data/PrgData relative to .text/PrgCode.

If a tool assumes it can freely relocate PrgCode and PrgData independently it would break this algo. (This isn't the case for probe-rs, I'm not sure it is for pyocd?)

Other flash algos do all data accesses relative to R9. Specifying -C relocation-model=ropi-rwpi seems to do R9-relative accesses, but that's known to be buggy in Rust: rust-lang/rust#54431

I'm not sure what's the best way forward here.

[Tiwalun]

I'm not sure what other tools do, but just renaming the .text section to PrgCode would help. The probe-rs tool can handle a missing PrgData section.

[flit]

I see. Given that RWPI doesn't work, it's probably best to not have the PrgData sections.

pyocd's algo parser can be updated to not require PrgData.

(pyocd does currently ensure that the PrgData regions are placed at the same offset from PrgCode as described in the ELF, so it would work regardless.)

[flit]

Updated the linker script to just change the output section name to PrgCode and not add PrgData. Included a comment documenting the section name and why .data and .bss are in the same section.

[Dirbaio]

👍 Nice, thanks!

If not having PrgData is a problem, maybe we can add an empty PrgData too.