Linker calculates wrong addresses for rodata section

Question

I have created a minimal example of my problem. In the c file I initialize an array with 16 elements. Then I call a function with the array pointer and its size as parameter. The function itself works, I've verified that with the disassembly file. Also the stackpointer initialisation works fine. The problem is that the function parameter of the array pointer is wrong. I checked it and the origin of failure is at the very beginning of the main section. Here the pointer gets stored on the stack.

What I don't understand: The array values are stored in the .rodata section. This section begins at 0x1000. So the pointer to the array should also be 0x1000. In the disassembly 0x1000 gets loaded into a5 (the right value). But then it loads the value of address a5 into a4. So 0x1000 represents a pointer to a pointer to the array, which makes no sense imho. Has anyone a idea what I'm doing wrong?

Here is all the information needed:

c program:

void test(uint8_t *array, int size){
    for(int i=0; i<size; ++i){
        LED_ADDR = array[i];
    }
}
int main(){
    uint8_t buf[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
    test(buf, 16);
}

linker script:

OUTPUT_ARCH( "riscv" )
ROMSIZE = 0x1000;
ROM_OFFSET = 0x0000;
RAMSIZE = 0x1000;
RAM_OFFSET = 0x1000;
/* provide variables for startup code (stack init) */
STACK_TOP = ( RAMSIZE + RAM_OFFSET - 4 );
ENTRY (start)
MEMORY {
    rom (rx) : ORIGIN = ROM_OFFSET, LENGTH = ROMSIZE
    ram (!rx) : ORIGIN = RAM_OFFSET, LENGTH = RAMSIZE
}
SECTIONS {
    .reset : { <PROJECTPATH>/obj/startup.o } > rom    /* startup code */
    .text : { *(.text) } > rom                        /* executable data */
    .rodata : { *(.rodata) } > ram                    /* read only data */
    .sdata : { *(.sdata) } > ram                      /* init vars */
    .bss (NOLOAD) : { *(.bss) FILL(0x0f); } > ram     /* uninit data */
}

disassembly file important parts: -in .text, beginning of main(): Pointer of array should be stored on stack I assume:

80:  000017b7    lui     a5,0x1      # a5 = first ram addr: begin of .rodata
84:  0007a703    lw      a4,0(a5)    # a4 = content of this addr?!?!?!
88:  fee42023    sw      a4,-32(s0)  # a4 gets stored on stack

-.rodata, contains values of array:

Disassembly of section .rodata:
00001000 <.rodata>:
1000:   0100
1002:   0302
1004:   0504
...
100e:   0f0e

EDIT:

My CPU is a havard architecture and it can't access data from the ROM directly. So .rodata and .data have to be in the RAM. My approach is that the program process writes the instructions into the ROM, but also writes the .rodata and .data into the RAM. My implementation of the Hardware facilitates this. (A script of mine separates these two datablocks of the binary and transcode it in a protocol my program unit can handle.)

And in the binary at first glance it works: .text is in the address space of the ROM and the .rodata and .data are in the address space of RAM. But the addresses to the .rodata, the linker calculates, are wrong.

This program of mine is only to test the functionality of this, I wouldn't write code like this otherwise. (The optimization flag is also -o0.)

So first of all, I'd like to understand the lines at the beginning of main(), that should put the array pointer onto the stack.

80:  000017b7    lui     a5,0x1      # a5 = first ram addr: begin of .rodata
84:  0007a703    lw      a4,0(a5)    # a4 = content of this addr?!?!?!
88:  fee42023    sw      a4,-32(s0)  # a4 gets stored on stack

Why is the linker treating the beginning of .rodata as a pointer to the array and not like the actual address of the array?

`i` is uninitialized in your code. Before you dig in such a deep, first fix the elementary things that are reported as warnings by your compiler. — Eugene Sh., Sep 06 '18 at 16:45
I typed in here manually, its not copied. In the original code it is proper initialized. But thanks for the hint, I correct it. — Martin Manzinger, Sep 06 '18 at 16:49
The [mcve] is meant to be a code copied *verbatim* from the one you have compiled and verified that it is reproducing the problem. Is it here? — Eugene Sh., Sep 06 '18 at 16:51
why is the linker script placing the readonly data `.rodata` in RAM? — user3629249, Sep 06 '18 at 17:17

score 2 · Answer 1 · edited Sep 06 '18 at 18:02

2

You have a lots of strange things in your linker script

.rodata is usually located in the ROM
```
.rodata : { *(.rodata) } > ROM
```
.data is in RAM but data is copied from ROM during the startup:
```
.data : { *(.data) } > ram AT > rom 
```
Your local variable buff does not have to be initialized from the .rodata. Compiler may optimize it just to store the immediate values form the code. It may optimize it completely and inline the test function. There are many possible optimizations as the code is extremely trivial. make the buff volatile and then compile.

edited Sep 06 '18 at 18:02

Jonathan Leffler

730,956
141
904
1,278

answered Sep 06 '18 at 17:55

0___________

60,014
4
34
74

I'd also recommend `static const buf[]`, or `volatile static const buf[]`. Without `static const`, the compiler is still likely to copy it to the stack (maybe from immediates). But yeah, `volatile` will stop the compiler from just fully unrolling the loop and using immediates. – Peter Cordes Sep 06 '18 at 19:05
I've added that to my question. – Martin Manzinger Sep 10 '18 at 06:47

Martin Manzinger · Answer 2 · 2018-09-10T10:10:27.917

I found out what's going on here: At the beginning of main, the values stored in the RAM at .rodata are copied completely into the stack. Therefore the pointer of the array points now into the stack and not on .rodata. That is not optimal and I may have to find out a way to optimize that and remove the redundant data. But anyhow this should work. What I forgot is to initialize not only the stack pointer but also the frame pointer. And there is another error in my hardware. That is why it hasn't worked. Thank you for your help!

Linker calculates wrong addresses for rodata section

2 Answers2