[MLton] experimental release 20051109

[Matthew Fluet]

>>> 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.

You should read
http://www.eecs.harvard.edu/~nr/pubs/ldbint-abstract.html
to see how amazingly simple debugging _should_ be.

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

Again, it's a question of having reasonable information to convey to the 
debugger, which we don't.  It wouldn't be very difficult to get a 
"control-flow" debugger as you describe, where we simply use the 
source information gathered for profiling to instrument the executable 
with its corresponding source location.  But, it is orders of magnitude 
more work to be able to inspect SML variables via gdb.