for review: stack dumps.

[Fergus Henderson]

On 04-Mar-1998, Tyson Dowd <trd at stimpy.cs.mu.oz.au> wrote:
> 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.

If you choose "no", the user should get a clear error message at
the time of the stack trace.  The disadvantage is that the error
message may not be able to say which files where not compiled with
stack trace information.

If you choose "yes", then the user will get a possibly confusing error message
at link time.  A possible advantage is that they will at least be able to
use "nm" on the object files to figure out which were compiled in which grade
(`nm foo.o | grep grade').  On the other hand, they can probably do the
same thing even if you choose "no" (`nm foo.o | grep stack_layout').
Still, grepping for `stack_layout' requires significantly more knowledge about
the compiler internals than grepping for `grade' after the linker
reports `symbol MR_grade_something_or_other undefined'.

The decision is marginal, but I'd suggest not adding it to MR_GRADE
unless/until it is made a proper grade of its own (with a `--grade'
option, etc.).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.