[m-dev.] for review: line numbers in the debugger (part 1)

[Zoltan Somogyi]

> > Support breakpoints on line numbers that correspond to calls.
> 
> Breakpoints are part of it; the other part is adding support to the debugger
> for display of line numbers (for *all* event types, not just calls).
> This should be mentioned in the log message.

This now reads:

Support line numbers in the debugger. You now get contexts (filename:lineno
pairs) printed in several curcumstances, and you can put breakpoints on
contexts, when they correspond to trace events or to calls. The latter are
implemented as breakpoints on the label layouts of the return sites.

> > compiler/call_gen.m:
> > 	Include contexts in the call LLDS instructions.
> 
> Could you explain in a bit more detail why the contexts
> need to be added in the call instruction?

This now reads:

compiler/call_gen.m:
	Include contexts in the call LLDS instructions, for association
	with the return site's label layout structure (which is done after
	code generation is finished).

> > +	% For labels which correspond to a call return (part (c) above),
> > +	% we record information in the third field during pass 4. If execution
> > +	% tracing is turned on, then jumpopt.m will not redirect call return
> > +	% addresses, and thus each label will correspond to at most one call
> > +	% return. If execution tracing is turned off, jumpopt.m may redirect
> > +	% call return addresses, which means that a label can serve as the
> > +	% return label for more than once call. In that case, XXXX
> > +	% this field can be updated after it is set. This updating requires
> > +	% taking the intersection of the live variables, and 
> 
> That comment is unfinished, and the XXXX is unexplained.

This now reads:

% For labels which correspond to a call return (part (c) above),
% we record information in the third field during pass 4. If execution
% tracing is turned on, then jumpopt.m will not redirect call return
% addresses, and thus each label will correspond to at most one call
% return. If execution tracing is turned off, jumpopt.m may redirect
% call return addresses, which means that a label can serve as the
% return label for more than one call. In that case, this field can be
% updated after it is set. This updating requires taking the
% intersection of the sets of live variables, and gathering up all the
% contexts into a list. Later, stack_layout.m will pick one (valid)
% context essentially at random, which is OK because the picked
% context will not be used for anything, except possibly for debugging
% native gc.

> What is the callees vector supposed to be used for anyway?

There presence would allow us to use faster code to check at every event
whether a breakpoint applies to that event, in the usual case that no context
breakpoint is on a line contains a higher order call. Instead of always
searching a separate data structure, as we now do, to check for the
applicability of context breakpoints, the code could search this data
structure only if the proc layout matched. Since we already search a table
of proc layouts in order to check for plain, non-context breakpoints on
procedures, this would have incurred no extra cost in most cases.

I implemented your other suggestions.

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------