[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