[m-dev.] For review: Stacks dump in the external debugger

Fergus Henderson fjh at cs.mu.OZ.AU
Sun Feb 14 23:22:01 AEDT 1999


On 12-Feb-1999, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> 
> | > One thing I can do is create a temporary file, put in it the output of
> | > MR_dump_stack_from_layout, reread it word by word and send them to the socket.
> | 
> | Ugh.  Horrible.
> | 
> | > Do you see some simpler to do that? (without rewriting all the stack_dump stuff)
> | 
> | How about changing the stack_dump stuff so that the function
> | `MR_dump_stack_record_print' is passed down as a parameter?
> | Then the internal debugger can pass down the current
> | `MR_dump_stack_record_print', and the external debugger
> | can pass down the address of a new function which prints
> | the data to the socket as a Prolog term.
> 
> But quite a lot of outputs are done via calls to fprintf(fp, ...) in
> mercury_stack_trace.c.

Only via MR_dump_stack_record_print() [see above],
in MR_dump_stack() [which you don't call -- you are calling
MR_dump_stack_from_layout()], and in MR_dump_nondet_stack().

Regarding the last of these, there are several possible solutions:
either (a) don't implement the `nondet_stack' command, or (b) implement
the `nondet_stack' command, but don't use MR_dump_nondet_stack() to do
it, or (c) implement the `nondet_stack' command, use MR_dump_nondet_stack()
to do it, and document what's wrong with this in an  /* XXX ... */
comment.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.



More information about the developers mailing list