[m-dev.] For review: calling MR_collect_filter() in MR_trace_real()
Fergus Henderson
fjh at cs.mu.OZ.AU
Tue Mar 6 20:21:08 AEDT 2001
On 06-Mar-2001, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> Fergus wrote :
> > [Erwan wrote:]
> | > @@ -1504,7 +1489,7 @@
> | > arguments = MR_list_empty()
> | > );
> | > }
> | > - MR_TRACE_CALL_MERCURY((*filter_ptr)(
> | > + (*filter_ptr)(
> | > MR_trace_event_number,
> | > seqno,
> | > depth,
> |
> | What happened to the MR_TRACE_CALL_MERCURY() macro here?
> | Why did that go away?
>
> Because I think they are unnecessary, indeed:
> MR_copy_regs_to_saved_regs() calls
> restore_transient_registers();
> save_registers();
>
> MR_copy_saved_regs_to_regs() calls
> restore_registers();
> save_transient_registers();
>
> Since MR_COLLECT_filter() is called just between MR_copy_regs_to_saved_regs()
> and MR_copy_saved_regs_to_regs(),
No, it's not; there are calls to MR_list_empty() and MR_trace_make_var_list(),
both of which can allocate heap. They increment the real MR_hp,
whereas the Mercury code that you're calling will expect the heap
pointer to be in the saved copy of MR_hp, so it will overwrite
the heap space that they allocate.
(This is assuming --gc none and non-SPARC architecture,
i.e. no transient registers.)
> I thought the macro MR_TRACE_CALL_MERCURY()
> was not necessary in that case.
I think it is, for the reason explained above.
Please send another diff when you've fixed that one
and the stuff mentioned in my other mail.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the developers
mailing list