for review: stack dumps.

[Tyson Dowd]

On 04-Mar-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 03-Mar-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > This adds stack traces (well, at the moment, just a "stack dump") to
> > the library and runtime system.
> > 
> > You need to compile with MCFLAGS = --stack-trace and
> > MGNUCFLAGS = -DMR_STACK_TRACE (or EXTRA_MCFLAGS and EXTRA_MGNUCFLAGS)
> 
> `mgnuc' should support a `--stack-trace' option (which would
> just enable -DMR_STACK_TRACE).
> 
> > to obtain an executable capable of displaying a stack dump.  This isn't
> > intended to be the final mechanism -- probably a new grade or debugging
> > grade would be the best solution.
> 
> Do you need to compile the whole thing (library, runtime, etc.)
> with MR_STACK_TRACE defined, or does it work OK if only part
> of the program is compiled with this flag?
> 
> Adding a new grade is not that hard.
> If this change introduces a new incompatible binary format,
> then you must at least change runtime/mercury_grade.h to
> include this flag in the mangled grade identifier MR_GRADE
> (which is used to ensure that the linker will catch attempts
> to link incompatible objects).

Technically stack traces aren't link binary incompatible, the executable
will work, and at worst you'll get a "label not found" error when doing
a stack dump.  For practical purposes, however, if you want a stack
trace and some of the object files aren't compiled with --stack-trace,
you might consider the executable broken.

Should I still add this to MR_GRADE?  I'm leaning towards yes.