[MLton-devel] debugging native assembly and line numbers

[Matthew Fluet]

> > Weren't we pimped by line numbers only being 16 bits?  

I've never seen the assembler complaining about constants being too big.

> > but if it is the assembler lines than I would think that we would
> > overflow.
> 
> We split assembly files to keep them small, although I don't know if
> we guarantee < 2^16 lines.

We don't guarantee anything, because we never split up an SSA/RSSA
function.  If you compile with -native-split 0, you'll get each SSA
function in its own .S file.  And, there's no lookahead, so once we start
outputing an SSA function, it all goes into the current file.

I've been bitten by having assembly files too big for the debugger; I
suspect that has to do with limited numbers of bits in the debugging
format for line numbers.  But that's only when I've been seriously
debugging the register allocator and running with -native-commented 5,
which tends to spew about 50-100 lines of comments per line of actual
assembly.  If Steve's just trying to get a ballpark location, he shouldn't
need that, although -native-commented 1 is really helpful as it will
distribute comments corresponding to machine IL statements relatively
close to the corresponding assembly.




-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel