mlprof

[Matthew Fluet]

> 3. fix mlprof to work with native backend

I've started in on fixing mlprof to work with the native backend.  I don't
forsee any problems with that, but I am getting strange behavior with
executables compiled with mlton -p or mlton -p -g.

Ex:

[fluet@lennon temp]$ mlton -p logic.sml
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Out of memory.
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Out of memory.
[fluet@lennon temp]$ ./logic 
Out of memory.
[fluet@lennon temp]$ ./logic 
Out of memory.
[fluet@lennon temp]$ ./logic 
Segmentation fault


[fluet@lennon temp]$ mlton -p -g logic.sml
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
gc.c 610: assert(isInFromSpace(s, *p)) failed.
Aborted
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
gc.c 610: assert(isInFromSpace(s, *p)) failed.
Aborted
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
gc.c 610: assert(isInFromSpace(s, *p)) failed.
Aborted
[fluet@lennon temp]$ ./logic 
gc.c 557: assert(p == max) failed.
Aborted
[fluet@lennon temp]$ ./logic 
gc.c 610: assert(isInFromSpace(s, *p)) failed.
Aborted
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
gc.c 610: assert(isInFromSpace(s, *p)) failed.
Aborted
[fluet@lennon temp]$ ./logic 
Segmentation fault
[fluet@lennon temp]$ ./logic 
gc.c 610: assert(isInFromSpace(s, *p)) failed.
Aborted
[fluet@lennon temp]$ ./logic 
gc.c 557: assert(p == max) failed.
Aborted


As far as I can tell, when profiling, mlton just links with -p (to link
with the profiling versions of the standard libs), and compiles .C and .S
files as though debugging were turned on; in particular, it doesn't call
gcc -p on the .C and .S files.  The other profiling specific actions take
place in the codegens, but nothing there should affect the executable in a
profound way: the c-codegen just adds profiling info in comments, while
the x86-codegen just adds additional labels.

The only thing I could think of was that profiling might rely on some
aspect of compiling from C.  The only place where the x86-codegen deviates
from what might be produced by a C compiler is the fact that it uses esp
and ebp as general purpose registers, and appropriately copies the stack
pointer back to esp when making a foreign function call or calling the
runtime system.  I make a quick hack to the register allocator to never
use esp or ebp as gpr's, and that reduced the frequency of segfaults and
assertion failures, but they still crop up.

Any ideas?  This is from the gprof info page, under
details/implmentation:

   However, some operating systems, most notably Linux 2.0 (and
earlier), do not provide a `profil()' system call.  On such a system,
arrangements are made for the kernel to periodically deliver a signal
to the process (typically via `setitimer()'), which then performs the
same operation of examining the program counter and incrementing a slot
in the memory array.  Since this method requires a signal to be
delivered to user space every time a sample is taken, it uses
considerably more overhead than kernel-based profiling.  Also, due to
the added delay required to deliver the signal, this method is less
accurate as well.

But, I thought signal handling was all working o.k. in MLton.  And,
grep-ing a little through the Linux 2.2.17 include files, it looks like
the system call might have been implemented, but I don't know if the
[g]libc libs have been updated to use it.