Access rights in RISC-V linkerscripts

Question

When programming ARM-based microcontrollers, I'm used to see a MEMORY{..} segment in the linkerscript like this:

MEMORY
{ 
    FLASH (rx): ORIGIN = 0x08000000, LENGTH = 128K
    RAM (xrw): ORIGIN = 0x20000000, LENGTH = 32K
}

The access rights are easy to understand:

r: read
w: write
x: execute

I'm making my first steps in the world of RISC-V based microcontrollers. The GD32VF103CBT6 microcontroller from GigaDevice has the following MEMORY{..} segment in its linkerscript:

MEMORY
{ 
    /* Run in FLASH */ 
    flash (rxai!w) : ORIGIN = 0x08000000, LENGTH = 64k
    ram   (wxa!ri) : ORIGIN = 0x20000000, LENGTH = 20k 

    /* Run in RAM */ 
    /* flash (rxai!w) : ORIGIN = 0x20000000, LENGTH = 15k */
    /* ram   (wxa!ri) : ORIGIN = 0x20003C00, LENGTH = 5K  */
}

How should I interpret these access rights?

These linker scripts are simply individuals that happened to write them based on their preferences and tastes. You dont have to put any access rights in the linker script, or you can spam it or anything in between, for ARM or Risc-V or any other target. One thing has absolutely nothing to do with the other. And as answered what they mean is in the linker documentation. Which is assumed to be gnu here since not specified, linker scripts are not assumed to be portable. — old_timer, Oct 18 '20 at 09:00
Likewise there isnt one linker script for arm and one for risc-v nor only one for GD32VF103CBT6, you happen to have one each that someone wrote for these cores not a universal this must be used for everyone kind of thing Most people are lazy and use the first thing they find, rarely do they take the time to learn as you are here, and then possibly adapt to their application. — old_timer, Oct 18 '20 at 09:03
Also understand the linker script has an intimate relationship with the bootstrap and often the C library (and application) so you cant separate them, you design them together More reason why folks stick with what they find rather than adapt to their application/solution. — old_timer, Oct 18 '20 at 09:06
Thank you @old_timer. Unfortunately most linkerscripts have only very little comments. I wish they'd be documented better. It would make a world of difference. Can you advice a good book, website or other resource to learn more about linkerscripts, bootstrap code and the relationship with the C library? — K.Mulier, Oct 18 '20 at 17:58
In the accepted answer is a link to the ld documentation. but also you have to just experiment that is part of it. 99% of bare metal work is reading and experimenting, relatively zero time is spent on the actual application. use other binutils tools along with ld, readelf. objdump, etc to see what the tool did. The file formats like elf are easy to write your own program to parse if those tools are not enough. Plus binutils is open source, no better docs than the source itself... — old_timer, Oct 19 '20 at 00:57
Hi @old_timer, thank you very much for the help. I'd like to get in contact with you. Can you drop me a mail? It's: `kristofmuliertelenetbe` with `` being `@` and `` being `'.'` (sorry for the weird way I put my email her, I'm just being careful for it not to be catched by web crawlers). Hope to hear from you soon :-) — K.Mulier, Oct 19 '20 at 11:12

score 1 · Accepted Answer · answered Oct 17 '20 at 16:19

They're not really "access rights", but rather "what kind of sections may be placed here".

From the GNU LD documentation (with some formatting mangled in the process of quotint :

The attr string must consist only of the following characters:

‘R’
Read-only section

‘W’
Read/write section

‘X’
Executable section

‘A’
Allocatable section

‘I’
Initialized section

‘L’
Same as ‘I’

‘!’
Invert the sense of any of the attributes that follow

If an unmapped section matches any of the listed attributes other than ‘!’, it will be placed in the memory region. The ‘!’ attribute reverses the test for the characters that follow, so that an unmapped section will be placed in the memory region only if it does not match any of the attributes listed afterwards. Thus an attribute string of ‘RW!X’ will match any unmapped section that has either or both of the ‘R’ and ‘W’ attributes, but only as long as the section does not also have the ‘X’ attribute.

With that background, I would interpret your config as follows:

flash (rxai!w) : ORIGIN = 0x08000000, LENGTH = 64k

...means that the "flash" region may contain anything except writeable sections, and

ram   (wxa!ri) : ORIGIN = 0x20000000, LENGTH = 20k

...means that the "ram" region may contain anything except read-only and initialized sections.

Access rights in RISC-V linkerscripts

1 Answers1