retrieving arguments in the trace

[Tyson Richard DOWD]

I've moved this discussion over to mercury-developers, because it's
worth recording this information in the mail archive, and others might
be interested in hearing about what is happening.

To allow others to see what has been said before, I've quoted more
than I normally would.

Zoltan Somogyi wrote:
> 
> Erwan wrote:
> > Tyson Richard DOWD wrote:
> > 
> > > When you say you want the information about variables that are
> > > input and output, do you need the insts? 
> > 
> > Yes, definitely.
> 
> Given that partially instantiated data structures are not supported yet,
> the only two insts you have to handle at the moment are free and ground.
> While other insts can occur, for the time being you can ignore programs
> that need them.
>

Indeed, I will probably add "free" "ground" and perhaps some notion
of uniqueness at first. Later I will add a full inst_info system.

> > > If so, would the information
> > > about the set of live variables at entry and exit be a convenient
> > > way to express this information?
> > 
> > We are not sure to understand exactly what you mean.
> > 
> > Does what you said mean that we will know the value of the "in"
> > variables only at CALL time and the value of the "out" variables only
> > at EXIT time ? 
> 
> This is currently the case.
> 
> > Is there a way to find out if there were non live variables in the
> > original clauses ?
> 
> Which variables are live depends on which program point you are talking about.
> "in the original clauses" is not a program point, so this question does not
> make sense.
> 
> > Let us tell you what we would like. For example, consider the
> > predicate pred with the following declaration
> > 
> >         :- type pred(type1::in, type2::in, type3::out) is det.
> > 
> > We want to be able to get the following kind of trace:
> >         ...
> >         CALL DET pred(a, b, X)
> >         ...          [X unifies with ab during the resolution]
> >         EXIT DET pred(a, b, ab)
> >         ...
> > 
> > If the predicate is semidet, at FAIL time we would like to be able to
> > display the values as they were at CALL time. Can you keep the
> > corresponding stack frame alive long enough so that we can retrieve
> > these values ? If not we would have to build our own stack (we would
> > like to avoid this as much as possible :-)).
> 
> Keeping the stack frame live until the exit or fail trace is not a problem;
> with the current tracing code, you already always have the stack frame when
> you call any of the trace functions (provided the procedure has a stack frame
> at all; some don't). The problem is keeping the input arguments alive
> in the frame.
> 
> It would be easy to modify the code generator to keep the input arguments
> live until exit, and only a bit harder to keep them live on failure. It
> would be more difficult to arrange for them to be put in locations that
> the tracer knew about at runtime, because this would require extending
> the argument passing convention. This would require us to choose between
> (a) not having information about the input arguments of library predicates
> at exit/fail ports; (b) having two copies of the libraries, one with
> each argument passing convention; and (c) having the standard library
> keep information about input args until exit/fail. Option (c) is definitely
> out, since it has too great an efficiency cost.
> 
> However, the real problem is that in the presence of destructive update,
> there is no guarantee that the contents of an input variable is still the
> same on exit as it was on call. You have to figure out how to cope with this
> before it makes any sense to do anything about preserving information
> until exit/fail.
> 
> At the moment the compiler does not generate code that does destructive update,
> and even when it does, we will be able to disable it if necessary. However,
> a significant number of hand-implemented library predicates do destructive
> update (the array and I/O modules for a start), and it does not make much
> sense to reimplement them without destructive update.
> 
> > A more subtle case is the one of the switches. At present we do not
> > have a clear idea of which variables we would like to display. We will
> > experiment with what you provide us with and see... This means that we
> > will most probably come back to you later with more requests, but we
> > do not see how to avoid the situation. Would you mind a lot ?
> 
> No.
> 
> > By the way, is there presently a way to retrieve the source level
> > variable names ? We thought that maybe code_info_get_varset could do
> > it ??
> 
> In what context do you want to do it? code_info__get_varset is the right
> way for code within the code generator, but code_info structures don't exist
> in the front end, in the optimizer, or at runtime.
> 
> If you are after the names of the arguments, that information does not
> exist anywhere in the system. Different clause heads may refer to the
> same argument by different variable names, or some/all clauses may have
> a term in a given argument position, so there is no natural correspondence
> between argument positions and variable names. Even if it so happens that
> all clauses refer to a given position by the same name, the compiler does
> not know this. Instead, it always refers to the arguments by variables named
> HeadVar__1, HeadVar__2, etc, which in the body are unified with whatever term
> occupied that position in the head.
> 
> If you are after the names of switched-on variables, again often they
> are compiler-introduced variables. You can find out their identities
> by looking at the HLDS dump of the procedure. It is present in comments
> such as
> 
> 	( % cannot_fail switch on `HeadVar__1'
> 	...
> 	)
> 
> The identity of the switched-on variable could be an extra argument to
> the trace event for entering a switch arm, but I don't think it would
> be that useful, because in the general case you still have to look at
> the HLDS dump (or something equivalent) to find out what the switch
> corresponds to (e.g. it could be a switch not on X but on the tail of X,
> which would probably be represented as a compiler-generated variable).
> 
> Zoltan.
> 
> 


-- 
       Tyson Dowd           # To fix this, edit BLAH\BlahKey\Blah\Whatever 
                            # in the registry.
     trd at cs.mu.oz.au        # *WARNING* Editing the registry can DESTROY
http://www.cs.mu.oz.au/~trd # your machine forever. Do not do it.