-g with -native

[Stephen Weeks]

> If it's possible, the *.n.s files produced by the native backend should be
> compiled with the -Wa,--gstabs option to gcc when mlton is invoked with
> -g.  Since gcc is mainly a C compiler, it only inserts debugging
> information when compiling a .c file; i.e., -g does nothing when compiling
> an assembly file.  Compiling with -Wa,--gstabs instructs the assembler to
> produce an object file with debug information pointing back to the .s
> file.  Unfortunately, you can't just add -Wa,--gstabs to all invocations
> of gcc, because then compiled .c files will have two sets (of probably
> conflicting) debug information.

Done.  Here's what the gcc calls now look like when compiling -g -native.

gcc -S -I/home/sweeks/mlton/include -g -w -fomit-frame-pointer -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -o /tmp/fileQuRrII.s /tmp/fileusayiD.c
gcc -c -I/home/sweeks/mlton/include -g -w -fomit-frame-pointer -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -o /tmp/file0FnLUQ.o /tmp/fileQuRrII.s
gcc -Wa --gstabs -c -I/home/sweeks/mlton/include -g -w -fomit-frame-pointer -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -o /tmp/filei1QNp0.o /tmp/fileXGq5SI.0.s
gcc -I/home/sweeks/mlton/include -g -w -fomit-frame-pointer -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -o wrong /tmp/file0FnLUQ.o /tmp/filei1QNp0.o -L/home/sweeks/mlton/lib -lmlton-gdb -lm -lgmp

> > The -Wa,--gstabs introduces one slight problem.  You want to do it if you get
> > a .s file from the native back end, but you probably don't want to do that if
> > the  .s  file  comes from another source.  (I.e., I could have my own library
> > routines written in assembler.)
> 
> Correct.  Although, I doubt many people would use MLton as a compiler for
> their assembly libraries.

I agree.  If people want to write their own assembly, they can always create a
library to link with.