On Fri, 2024-12-06 at 16:51 +0100, Georg-Johann Lay wrote:
>
> The CRC tables ARE put into .rodata, not into .data.
>
> The correct question is: Why is avr putting .rodata into RAM?
>
> Suppose the following C code:
>
> char read_c (const char *p)
> {
> return p[1];
> }
>
> Where p may point to .rodata, .data, .bss etc.
> Now suppose .rodata is located in flash and .data and .bss
> are located in RAM.
Thanks for the detailed explanation!
I feel you. I've been coding on mcs51 MCUs for a couple of years now (on
SDCC, meh)
> This would imply that there is some means to tell apart
> different address spaces by looking at p. This is *not* the
> case. In particular, flash address 0x4 looks exactly the same
> like RAM address 0x4. Both are 16-bit address 0x0004, and there
> is no way to tell them apart.
>
I'm a little surprised that there's no way to get pointer/symbol meta-
information from within the backend code to identify data being accessed
that will end up in __code / __flash / .rodata / .text.
On SDCC/mcs51 things are simple enough so that we can at least try to lookup
a given symbol from the backend code and see if it's got a known address
space assigned to it (via (forward) declaration). This can be used to
optimize accesses to e.g. SFRs even during later stages of compilation.
Best regards,
Oleg Endo
