profiling bug understood

[Henry Cejtin]

Ok,  I  now completely understand the profiling bug.  The problem is that the
call to sigaction in the profiling startup code does not set  the  SA_ONSTACK
flag.   Thus when the profiling signal arrives, it will use the current stack
pointer.  If you are in C generated code, this is fine, but  if  you  are  in
assembler  generated  code, then the stack pointer register is probably being
used for something else and you will not be happy.

The moral of the story, which is not bad any way, is that we will just  write
our  own  profiling  startup and shutdown code.  This is pretty trivial and I
have never been very happy with the versions in glibc  any  way.   I'll  hack
something together tomorrow.  I will also take this opportunity to change the
bin size from 2 bytes to 4.  The 2 byte size REALLY SUCKS.  Since  the  clock
runs  at  100  Hz,  it  only  takes 655.36 seconds, or a bit under 11 minutes
before it might wrap.  I have seen cases where the run time  is  sufficiently
concentrated  that  it did overflow some bins in 30 minutes.  This results in
incorrect results.  You can detect that something happend if you  keep  track
of the user+sys time and compare that to the total number of ticks.  Going to
4 bytes means this will never happen unless the run  takes  at  least  1  CPU
year.

Matt, if there is anything else you would like to change in the gmon.out file
format, tell me and I'll put that in.

Once the new mlprof is done, the mlton script should be changed  since  there
will no longer be any reason to compile things with -g when you are profiling
(because all the information will be  in  static  symobls  instead  of  debug
tables).