Read-only static data location?

[kripken]

A user hit a case where static memory was being trashed it seems. Talking with @dschuff , if we knew where read-only static data was, we could make SAFE_HEAP check for any writes to there.

Does the linker have that information? We need to differentiate the read-only data from the read-write and bss sections, basically. cc @sbc100 @tlively

[sbc100]

Yes this should certainly be do-able. I think the linker should provide a symbol for that, although I don't think we do today.

It does looks like we already put the .rodata segment first when linking the final binary.

[sbc100]

Sadly it looks like we can find the end of the data and end of the bss using some old legacy C symbols:

NAME
       etext, edata, end - end of program segments

SYNOPSIS
       extern etext;
       extern edata;
       extern end;

DESCRIPTION
       The addresses of these symbols indicate the end of various program segments:

       etext  This is the first address past the end of the text segment (the program code).

       edata  This is the first address past the end of the initialized data segment.

       end    This is the first address past the end of the uninitialized data segment (also known as the BSS segment).

wasm-ld supports these but sadly they are not what we want here.

We can also get the start and end of any sections that is a C identifier. So if you put a data symbols in sectiion foo the linker will magically create __start_foo and __end_foo symbols on demand. However this is not true for section like the builtin ones that are C identifiers (e.g. .rodata which is the one we want here.).

So I think we either need to create a new magic symbol for erodata or we find some way to safely extend the __start_/__end_ symbol creation to non-C-identifiers that is safe against collisions.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[dschuff]

This still sounds like it might be useful.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.