[MLton] power pc "port"
Matthew Fluet
fluet@cs.cornell.edu
Wed, 1 Sep 2004 09:12:40 -0400 (EDT)
> The multiple defintion problems are because Mac OS X's libSystem
> (equivalent of libc) uses the gdtoa library. However, it doesn't export
> the gdtoa symbol. So we may just have to live with these warnings (there
> is a switch somewhere to suppress them).
There must be ways that other projects that use gdtoa get around it.
> The IEEEReal_getRoundingMode and IEEEReal_setRoundingMode errors are
> an oversight - I'll have to hack runtime/basis/IEEEReal.c to have a
> PowerPC case.
Yes.
> The spawnve and spawnvp errors are a puzzle to me. I don't see where in
> the MLton code these functions are defined. Is there a dependant library
> that I'm not seeing? (I can easily implement these functions, but I don't
> want to do that if they're already out there somewhere.)
As far as I can tell, we are pulling it from libc. For most platforms, I
suspect that whatever header file the prototypes are really in has more
stuff than we need, so there is an explicit
runtime/platform/spawn.h
that is included by linux.h, {free,net,open}bsd.h, and solaris.h,
but cygwin.h and mingw.h get it from <process.h>.
However, that doesn't explain the linker not finding the symbols. Maybe
they are in a different library under Mac OS X.
> The etext error may turn out to be annoying. The MLton GC uses the _start
> and etext symbols to figure out where the text segment sits.
> Unfortunately, the Mac OS X linker doesn't offer an etext symbol. It
> does, however, offer functions that give similar information: get_etext(),
> get_end(), and get_edata(). However, the manual page (see
> http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/end.3.html)
> makes clear that you're not really supposed to rely on those. Perhaps if
> a MLton GC expert could tell me exactly how etext is used, I can hack the
> GC to be more Mac OS X-friendly.
The _start and etext symbols are used for profiling. Essentially, the
time profiler works by raising a timer interrupt and incrementing a
counter corresponding to the program counter of the interrupted
instruction. The _start and etext symbols are used to determine which
addresses correspond to instructions from the executable (as opposed to
instructions in a dynamically linked library or in the kernel).
Profiling is probably the last thing you want to tackle, and looking at
the manual pages, I suspect that we're going to have to work hard to get
it working on Mac OS.
For now, I would suggest setting
#define HAS_TIME_PROFILING FALSE
in platform/ppc.h (or whatever you call it). That will avoid all the time
profiling stuff in gc.c including the _start and etext symbols.