[MLton] experimental release 20051109

[Wesley W. Terpstra]

On Nov 15, 2005, at 1:58 PM, Matthew Fluet wrote:
>> If the files were compiled with '-g', you'd have debug
>> information which told you the 'line number', which
>> in this case would be the ProfileLabel. I don't know
>> how hard/portable reading debug info is, though.
>
> Also, I don't know how hard it is for a program to inspect its own  
> debug info while running.

AFAICT, you would need to find your own binary using
argv[0], and then read the debug info to build the IP map.
It might be the case that the debug info gets loaded into
the core already, but I don't think this happens.

So basically only the initialization phase would differ
from what we have now. After that, you still have your
big lookup table to consult on each timer expiry.

The stabs format is amazingly simple. You would only
need to parse the SO and SLINE records to get the info.

Try using 'nm -ap' on a program compiled with '-g'.
It's really enlightening.

We would need to have larger gaps between profile
labels too, unless you want to reset the source file at
each line of the C file (otherwise, it gets incremented).

I am still trying to grok how the stabs get changed
on their way through the linker, once I have got this
figured out, I will try to write a prototype program that
generates the IP map out of a provided MLton binary.

An alternate solution would be to just dump all the
IP values sampled during the run, and translate it
into the actual profile labels in mlprof. That way there
is no need for the profiled application to open itself.

There might be a portability problem in finding the
stabs data in a binary, since windows, ELF, and
Mac OS X have different executable formats...
OTOH, I bet you could inject a really unlikely string
into the stabs, and then search for it to avoid this.

>> Actually, doing this would be really cool anyways!
>> If every output C line tracked where it came from
>> in the actual SML source, you could run the program
>> via gdb and actually see the SML line being executed.
>
> That's a bit harder, since the profile labels don't directly map to  
> source lines.

Here I was imagining outputting the actual source lines
for the case when you are not profiling. You should read
http://sources.redhat.com/gdb/download/onlinedocs/stabs_toc.html
... it's amazing that this is all the information gdb needs.

Using stabs (via x86 codegen or inline asm) we could
get MLton to be debuggable via gdb. So cool!