Andy Wingo <wi...@pobox.com> skribis: > On Mon 20 May 2013 18:37, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo <wi...@pobox.com> skribis: >> >>> On Sun 19 May 2013 23:52, l...@gnu.org (Ludovic Courtès) writes: >>> >>>> I guess literal strings would go out as per ‘SCM_IMMUTABLE_STRING’ >>>> (which needs relocation), right? >>> >>> Yep. Right now the stringbuf goes into read-only memory, but the string >>> itself goes in writable memory as it needs its link to the stringbuf >>> fixed up (relocated) at runtime. >> >> OK. It could be in a PT_GNU_RELRO segment, which the loader (well, the >> other one, from glibc ;-)) remaps read-only after relocation. >> >> [A moment of enlightenment when one realizes what it means to have our >> own ELF toolchain. :-)] > > Right :) We don't need to rely on the loader, and in fact should not in > general do so. Some "relocations" are actually more complicated than > what glibc does; for example, for symbols or keywords.
Yes. I meant, there are things Guile’s loader could remap read-only once the relocations are done, as glibc’s loader does for PT_GNU_RELRO. >>> (I suppose we should be careful about embedded NUL characters; perhaps >>> we should use some other format for the string tables.) >> >> NULs in string contents should not be a problem, as long as there’s >> info somewhere about the string length, no? > > There isn't -- not in ELF string tables. They're NUL-terminated. > >> UTF-8-encoded ELF symbols may be more of a problem. How could NULs in >> symbols be handled? > > Well we can just use some other data structure that's not a standard ELF > string table; since we have the linker and loader and we are defining > custom sections (.guile.docstrs for example) we can do what we like. OK. Ludo’.
