Re: XNU sys_fork syscall (0x02). Linux vs XNU

On May 1, 2008, at 1:27 AM, Robert Spykerman <email@hidden> wrote:

PS I take it you're probably gonna really say no no no no too to what we were kind of planning to do the mach-o header? :) - ie hack it so that the entire forth dictionary gets written back to disk within the same executable, when the user so chooses to do so? :)

I actually felt that was a rather clever hack, and had already considered something similar for checkpointing information (I decided against it because of the cardinality of users vs. binaries/instances vs. binaries, for non-GUI apps).

I would caution you, however, to try to get a section type assignment, or to try to overload one that is not loaded by the kernel loader or used/loaded by dyld by default via the vnode pager. I'm not sure what hoops are there for that, but I'm pretty sure FORTRAN went that route.

For that to work out for you, you will need to identify the binary which is currently running from within itself, and use the resulting path to refine the file. From there, your startup code could load the dictionary.

The disadvantage here is it leaves you an execute/open window during which the binary can be overwritten/swapped out/renamed/replaced. If you accept that window, then you might as well write the dictionary as a bundle file, and save yourself some grief, as well as avoiding keeping the executable writable.

The advantage is that, since you are not hacking pages that go through the vnode pager as normal data/text/BSS pages, you are not breaking your ability to code-sign the code. If the pages look like any other data/code pages, you might get unhappy fast, since there will be no signature over that range, unless you re-sign it on each save.

I'm actually not sure about mmap'ing them, either; you may have to read them into allocated data instead (if so, and you actually run into trouble with mmap, file a bug, since that's not a case I think anyone's specifically considered).

-- Terry