console

console

[Tom Tromey]

A few weeks ago I sent Jim some code to let Insight use xterm as the
console window.  But while debugging gcc I've come to realize that
this is overkill for many applications.

gcc has some very complex data structures and some functions to print
these out.  I'd like to use these, as opposed to Insight's display
features, because the gcc functions are still easier to use.  However,
having a separate xterm (right now, the xterm from which I started
gdb) for this is a pain.

So, in some situations at least, it would be very convenient to have
the inferior's stdout be shown in the gdb console window.

Tom

Re: console

[Fernando Nasser]

I agree.  Both solution have their merits.

Can't we make it selectable?

Fernando


Tom Tromey wrote:
> 
> A few weeks ago I sent Jim some code to let Insight use xterm as the
> console window.  But while debugging gcc I've come to realize that
> this is overkill for many applications.
> 
> gcc has some very complex data structures and some functions to print
> these out.  I'd like to use these, as opposed to Insight's display
> features, because the gcc functions are still easier to use.  However,
> having a separate xterm (right now, the xterm from which I started
> gdb) for this is a pain.
> 
> So, in some situations at least, it would be very convenient to have
> the inferior's stdout be shown in the gdb console window.
> 
> Tom

-- 
Fernando Nasser
Cygnus Solutions (a Red Hat company)    E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: console

[Andrew Cagney]

Tom Tromey wrote:
> 
> A few weeks ago I sent Jim some code to let Insight use xterm as the
> console window.  But while debugging gcc I've come to realize that
> this is overkill for many applications.
> 
> gcc has some very complex data structures and some functions to print
> these out.  I'd like to use these, as opposed to Insight's display
> features, because the gcc functions are still easier to use.  However,
> having a separate xterm (right now, the xterm from which I started
> gdb) for this is a pain.
> 
> So, in some situations at least, it would be very convenient to have
> the inferior's stdout be shown in the gdb console window.

Ha! Trivial ;-^

I believe the work required goes something like this:

	o	get insight / GDB sharing a common
		event loop (the TK one I guess)

	o	have the program output routed
		to gdb where it can in turn (gdb_stdtarg)
		route it through to the console

it should be possibile to attack the two parts fairly independantly.

	Andrew

Re: console

[Kai Ruottu]

Andrew Cagney wrote:
> 
> Tom Tromey wrote:
> >
> > So, in some situations at least, it would be very convenient to have
> > the inferior's stdout be shown in the gdb console window.

 Yes, that 'older' environment with once more than 100 million users,
and which doesn't have a 32-bit system console (just guess what...)
> 
> I believe the work required goes something like this:
> 
>         o       get insight / GDB sharing a common
>                 event loop (the TK one I guess)
> 
>         o       have the program output routed
>                 to gdb where it can in turn (gdb_stdtarg)
>                 route it through to the console
> 
> it should be possibile to attack the two parts fairly independantly.

 Finding the place where the program output happens, ie. where the
simulation of the 'write()' in the simulators in the 'sim' subdir is,
and #ifdef'ing the pure 'write()' there with something like
'callbacks->write_stdout(callbacks,....)' for the 'no-console-available'
case has been quite easy for most targets, but the PowerPC and the psim
seems to be very tough. Not any kind of succes yet, although I found a
pure write() in 'sim-io.c' (or something), using the callback-route had
no influence... Perhaps the route to the GDB-console is somehow broken. 

 Hmmm, who then could know something about 'psim' :

-------------- clip -------------------------------------
PSIM - Model of the PowerPC(tm) Architecture 

Copyright (C) 1994-1996, Andrew Cagney - cagney@tpgi.com.au 
-------------- clip -------------------------------------

 So it can be possible that I ask this from the right person...

 Ok, I have managed to get Insight/GDB, based on an older version (98r2)
of it to work under DOS/Win3.1x/Win32s, using my Mingw32s-port (or I
must invent a new name into this if Mingw really is not allowed to
support Win3.1x...) to build the executables. Perhaps I'll try to adopt
things from the current snapshots, using them straight resulted into a
weird Insight with a fully grey source window with no sources, no status
line etc. Updating the 'bfd', 'opcodes', 'readline' etc. (the gdb-engine
probably too, I have now a partially updated gdb-4.18) into the current
level has already succeeded. The Mingw-Win32 host showed that it can be
quite possible to get  near the current snapshots... The 'gdbtk-*.c'
stuff seems to be the problem (with the mixed tcl/tk-8.0pl2/8.04 DLLs I
have now for Win32s). 

 If someone could give a hint where the 'output to the system console'
is hiding in the psim sources, I would be grateful...

Cheers, Kai

PS. Peaceful Easter to everyone !