elf has a LOAD segment with RWX permissions when using .RamFunc functions

[RobDeatherage]

I've seen other posts to resolve the compiler warning of "elf has a LOAD segment with RWX permissions", but I'm receiving this warning only when calling functions in RAM using the .RamFunc segment attribute.

From the map file I've verified the function is being loaded into RAM.  I could disable the warning, but would like to understand the underlying issue.

I'm working with the latest STMCubeIDE version 1.16.0, but also saw this in 1.15.0.  I'm building code for the STM3H735 and STM32H745 families.

[TDK]

Issue is probably write + execute. Typically you don't have write permission to sections where you are executing code. Code should be static.

Try the READONLY attribute.

ld - GNU Linker: ELF has a LOAD segment with RWX permissions. Embedded ARM project - Stack Overflow

[Pavel A.]

The .ld files shipped with CubeIDE have the "w" attribute for the internal flash. (For 'historic reasons' ?)

Actually the flash can be declared as "rx" because it is not writable from the linker POV. The linker does not care about runtime behavior, it is not aware of MPU and so on. So it's up to the developers how they get rid of this warning.

[RobDeatherage]

TDK,

Admittedly I'm relatively new to the GCC realm, and I appreciate the support.

The examples from the link you provided are referring to functions in flash, and my linker file already has READONLY attribues for all flash sections.

I've taken my original function definition of:

__attribute__ ((section (".RamFunc"))) void SomeFunction(void)

and instead, tried:

__attribute__ ((READONLY, section (".RamFunc"))) void SomeFunction(void)

but the compiler now gives an addditional warning of 'READONLY' attribute directive ignored [-Wattributes].

Am I missing what you've recommended to eliminate this warning?

[TDK]

You should make the changes in the linker file, which is a *.ld file, generally in the top level directory of the project.

Can you attach your linker file?

[RobDeatherage]

I had to convert to a .pdf as .ld formats are not supported.

[Pavel A.]

The RAM code (by contrast with flash) indeed is in memory both writable and executable. So now you do understand the reason and can disable the warning.

[RobDeatherage]

Paul,

I agree to some extent, but only if the warning could be suppressed for each individual function.  The warning could be beneficial in other scenarios.

Knowing memory is both writable and executable, what I would expect is for the Linker to have a little more intelligence and ignore this waring when raised due to .RamFunc functions.

I appreciate the feedback.

[TDK · Accepted solution]

The warning is there because you're executing from a section that is writable, so a bug in the code that allowed an out of bounds write or a buffer overflow could allow for arbitrary code execution. It's not a per-function warning, but a general "this section is problematic because you can write to it and execute from it" warning. Any sort of per-function flag wouldn't address the core issue.

[RobDeatherage]

The points you and Paul have made make sense and I appreciate your feedback.