mlprof-native broken

[Matthew Fluet]

> I'm confused: surely you meant that with -s you get the `t' in addition to
> the `T', not the other way around.  (`T' are the non-static functions and
> `t' are the static ones.)

> In the latest version, if you run
>     mlprof go mlmon.out
> you will see that it claims 2.51% for GC_foreachPointerInObject and  1.73%
> for GC_foreachPointerInRange.  If you then do `nm -na go', you will see
> that there are no static symbols adjacent to these two, so I claim that
>     mlprof -s go mlmon.out
> should  attribute exactly the same percentage to these two.  Despite
> this, if you run
>     mlprof -s go mlmon.out
> then neither of these routines appear at all.

O.k.  Maybe we're just talking past each other.  Here are the relevant
parts of the old mlprof that I was using to write the new one:

-- defined at the very top of the file, so by default labelStatic is true
val labelStatic = ref true (* include static C functions *)

-- part of the reg exp for reading nm -n output, this seems to me to be
-- saying that "t" is non-static (always included) and "T" is static (only
-- included when labelStatic = ref true).
		 save(contains(if !labelStatic then "tT" else "t"), kind),

-- just a comment
 * Static functions appear iff labelStatic.

-- in the processing of the options, so -s turns off display of static
-- functions.
		     ("s", falseRef labelStatic),

Is this backwards?  What do we want mlprof to do?  In particular, does -s
mean turn on or turn off display of static functions.  I think my proposal
below is the best way to go: like the -d switch, -s expands the static
functions to more detail.

> Although  it  is  really impossible to tell where one function starts and the
> next one finishes, in fact I have never seen a C compiler which put part of a
> function  before  (i.e.,  in  lower  addresses)  than the entry point for the
> function.   The  reason  is  that  there  is  typically  some  register/stack
> shuffling  that  goes  on  at function entry, so there would be no advantage.
> I.e., functions start at their entry point.  Where functions  end  is  a  bit
> trickier  if  you  don't  look  at static functions since one can have static
> functions in a file both before and after a non-static  function.   Again,  I
> haven't  seen very many C compilers that change the order of functions in a C
> file, and since I always write my C  code  top-down,  the  order  is  that  a
> function  ends when the next one starts.  (This is certainly what C profilers
> have traditionally done.)  If you do look at static functions  then  this  is
> definitely correct.

** This is part of a postponed email, so take the -s comment with a grain
of salt; but this is being done in the current version of mlprof that I
sent out.

So, maybe the correct thing to do is to always break up code ranges by
looking at static functions, but coallesce all of the static functions
into one label "<static>" unless the -s switch is used.  i.e., we would
always always compute the most detailed information, but only display it
when -s was used.