On Thu, 2003-02-13 at 09:10, Andrew Cagney wrote:
I'm pretty sure that with your main.c change in (and gdbtk.c changed to
register "insight" instead of "gdbtk", insight will at least `work'.
Yes.
That just leaves the core dump which is comming from gdbtk_init() not
being called in all cases :-( There, the fix, I think, involves
modifying the interps.h:init interface so that it takes an argv0 parameter.
We could do that. I hacked around it by having an init_ui_hook save off
argv0, which the real gdbtk_init would use. If you'd like me to submit a
patch adding argc and argv (I think we might do this to facilitate
command-line processing options), just let me know, and it'll be out of
my inbox as fast as I can type.
I think killing off init_ui_hook (and pass in argv0) is better. Get's
insight `ahead of the pack' here. Then, once the tui reference is
flushed, that hack can die (ya!).Note that the real problem with insight is that gdb_std* have not yet
been properly set up, since that gets done inside the resume_proc. So by
naively calling gdbtk_init in init_proc, a whole bunch of stuff happens
that could cause output to one of these streams. Simple fix: don't allow
insight to run the startup script until interp_resume is called. This
will probably be needed when/if we get dynamic interpreter switching
working (insight to cli and back again).
The way the interps stuff thinks that the ui_out should be passed in
during interpreter registration (and not initialization) just doesn't
feel right. That part needs a re-think.With the changes I've made to my sandbox, my insight does not crash. The
only casualty is "-w"/"-nw". IMO, "-w" is not a loss for gdb. For
insight, we can always have core gdb interpreter "-nw" means
"-i=console". I think this is a safe enough assumption, but as you say,
this is something which we'll talk about on the gdb list once this dust
all settles.