[m-dev.] for review: fix stack traces (runtime)

[Tyson Dowd]

On 16-Apr-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> >  	(const Word *) &mercury_data__stack_layout__##e,		\
> > +	(Integer) -1,		/* Unknown label number */		\
> >  	(Integer) -1,		/* Unknown number of live values */	\
> > -	(const Word *) NULL	/* No list of live valeus */		\
> > +	(const Word *) NULL,	/* No vector of live values */		\
> > +	(const Word *) NULL,	/* No vector of variable names */	\
> > +	(const Word *) NULL	/* No vector of type parameters */	\
> 
> The semantics of the label record says that if the number of live values
> is zero, the other fields are not valid (and thus need not be present).
> This should also be the case if the number of live values slot has a
> negative number. This should save a few words in the library and runtime.

Ah yes, I'd forgotten about that.  I'll make it zero, and remove the
rest of the fields.  -1 just meant "unknown number of live values", 
since 0 means "no live value information", I think it will do just as well.

> 
> > +		if (determinism != -1) {
> 
> Why don't you say
> 
> 		if (determinism < 0)
> 			break;
> 
> This makes the test more robust, avoids executing it twice, and gives
> you one tab more room.
> 
> A comment saying what a negative determinism signifies would also be
> nice, since I for one don't know what it means.
> 
> > +				fprintf(stderr, "\t%s\n", label->e_name);
> 

It now looks like this:


	do {

		... get label info ...

		/* 
		** A negative determinism means handwritten code has
		** been reached.  Usually this means we have reached
		** "global_success", so we should stop dumping the stack.
		**
		** Otherwise it means we have reached some handwritten
		** code that has no further information about the stack
		** frame.  In this case, we also stop dumping the stack.
		*/
		if (determinism < 0) {
			break;
		}
		... traverse stack frames ...

	} while (TRUE);


> mercury_label.h has
> 
> typedef struct s_label {
>         const char      *e_name;   /* name of the procedure          */
>         Code            *e_addr;   /* address of the code            */
>         Word            *e_layout; /* layout info for the procedure  */
> } Label;
> 
> The comment on e_layout seems wrong, since to be useful for agc, the
> pointer must be to the layout info for the label, not the procedure.

It's wrong, yes.  It's a bit old.  I've fixed it in this change now.

> The e_name field is now redundant. The name of the procedure can be assembled
> (in a user friendly form even) from the pieces in the procedure layout info,
> which is accessible from the label layout info. Removing it would also

No, profiling still uses it (although I belive Tom is working on that).

But for this application we don't need it -- I have another change
on the way that uses the name information from the layout_info instead.

When profiling doesn't use it anymore, we can remove the field.  We
could get the space benefits before profiling is changed using some
hacky macros, of course.

> reduce data space requirements significantly. The duplication of info that
> is also the procedure layout (in a format which is more amenable
> to factoring out the common module part, the module name) would be gone.
> This duplication was probably responsible for a large part of the
> extraordinary increase of the (-g, Alpha) executable size from 8.x Mb to
> 62.x Mb with --generate-trace.
> 
> The layout records for labels in hand-written code may need to be
> provided with a pointer to a sufficiently meaningful procedure layout
> record if this were done. OTOH, many if not most of these should
> probably be skipped by the stack trace anyway.

I expect one day to extend the macros to make more meaningful stack
layouts. At the moment, we just stop if we come across a stack layout
without enough information.

> 
> I don't believe we ever need the e_name field for a label which has
> no layout record. In fact, I don't believe we ever need a label table entry
> for any label which has no layout record, except maybe for profiling.
> Does anybody know of such a need?
> 
> If my supposition is true, or can be made true with minimal effort, we can
> avoid emitting the non _sl versions of the label init macros.

Don't the init macros also intialize code addresses for use in grades
without static code addresses?

-- 
       Tyson Dowd           # There isn't any reason why Linux can't be
                            # implemented as an enterprise computing solution.
     trd at cs.mu.oz.au        # Find out what you've been missing while you've
http://www.cs.mu.oz.au/~trd # been rebooting Windows NT. -- InfoWorld, 1998.