Re: rtl metadata musings

[ludo@gnu.org (Ludovic Courtès)]

Andy Wingo <wingo@pobox.com> skribis:

> On Mon 20 May 2013 18:37, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> skribis:
>>
>>> On Sun 19 May 2013 23:52, ludo@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’.