Re: @MLton load-word and MacOSX 10.7 (Lion)

Matthew Fluet <[email protected]> Tue, 19 Jun 2012 10:55:47 -0400
Newsgroups gmane.comp.lang.ml.mlton.devel
Message-ID <CAMrhFL7Q+fXuP3Eg5hpT8S6nPAJCp7NKC4Fd6d9-L9PaD88XyQ@mail.gmail.com>
On Tue, Jun 19, 2012 at 6:19 AM, Wesley W. Terpstra <[email protected]> wrote:
> On Mon, Jun 18, 2012 at 5:16 PM, Matthew Fluet <[email protected]> wrote:
>> I agree that (a) makes the most sense.  I'll add a note to the
>> documentation on MLton.World that saving and loading worlds won't work
>> with position-independent executables.  As I noted before, '-link-opt
>> -fno-PIE' seems to do the trick on MacOSX Lion.
>
> I believe -fno-PIE just clears the MH_PIE bit at link time. So, the
> code remains position independent, but the loader just doesn't try to
> relocate it.

O.k., that makes sense.  At link time, one wouldn't expect significant
rewriting of the object files.  If they were position independent when
compiled/assembled into the object file, then the executable code
would remain position independent in the executable.

> How will this play out if you use a MLton-built library? It seems to
> me that we could run into this problem even without ASLR. If another
> library the program links changes size, it might cause the MLton
> library to get pushed out of the way and cause the same breakage. On
> the other hand, I guess one doesn't expect "load-world" between
> recompiles of a program and loading new libraries is just a step
> worse.

Indeed, a MLton compiled executable gets a (random) magic number that
is stored with a saved heap.  "load-world" fails if the magic number
in the saved heap does not match the magic number in the executable.

It is, however, true that a MLton-built shared library could be loaded
at different addresses, even if the main executable is not a PIE.  I
think the best option in such a situation would be to build a static
library and link that into a non-PIE.

But, at the same time, I'm not sure of the utility of MLton.World.save
for such a library.  If the SML code isn't "in control", then it seems
that there is likely to be a lot of C-side state in the the program,
which wouldn't be saved/loaded.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/