I believe I may have found a way to provide a console for Linux GDB users.
The steps are:
- Create an Xterm
- Note the /dev/pts/# for that xterm
- Redirect the program I/O to that xterm
Proof of concept:
In a terminal window, issue the who command and note the second colume.
Mine shows:
(http://img405.imageshack.us/img405/866/126yr4.png)
Now start an Xterm. Issue it as "Xterm &" to keep your current terminal active.
And issue the "who" again. Note the new pts number representing the new tty /dev/pts/{some new number}
Mine looks like: /dev/pts/1
(http://img106.imageshack.us/img106/2666/127wi1.png)
Issue a line of text to that tty. Like: echo "This is a test" >/dev/pts/1
Note that the output appears on the newly opened Xterm.
Now for Input. From terminal number 1, issue the command "cat </dev/pts/1".
From the new Xterm issue a couple of Ctrl-J to clear whoever is waiting for input, then you should see your typed chars redirected from New Xterm to the old terminal.
(http://img246.imageshack.us/img246/5992/128hz9.png)
To get out of the situation, Ctrl-C on the old terminal.
Now for gdb: compile the following pgm as a Linux console pgm, making sure to use -g flag. I named my pgm "conio".
#include <iostream>
#include <cstdlib>
#include <cstring>
using namespace std;
int upstring(char *value);
int main()
{
char value[81]={'\0'};
int upper_count;
cout << "Please type in a String (max. 80 characters): ";
cin.getline(value, 80);
upper_count=upstring(value);
cout << upper_count << " characters are converted" << endl;
cout << "The new string is now: " << value << endl;
return EXIT_SUCCESS;
}
int upstring(char *value)
{
int i=0;
while(*value)
{
if(islower(*value))
{
*value=toupper(*value);
i++;
}
value++;
}
return(i);
}
Run the pgm in terminal 1 like:
gdb consio
run </dev/pts/1 >/dev/pts/1
The gdb I/O stays in its own terminal, and the users I/O is redirected to the new Xterm.
(http://img254.imageshack.us/img254/5124/129hy4.png)
The input is a bit problematic. I have to use Ctrl-J's to end a user input line in the Xterm (not a carriage return) and the prompt existing before the program started has to be cleared or else bash sees the input as a "bad command".
Also, chars dont seem to echo at the Xterm when the user is typing them in.
I think these problems might be solved with escape sequences redirected to the new Xterm.
But I'm no Xterm guru. Just hacking here.
The redirection on the run command can also be done with a "set inferior-tty /dev/pts/1" gdb command.
The point here? That the debugger plugin could control an Xterm console for the Linux user just as it does for Windows users.
Would some of you *nix guru's comment on this?
References:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=7336&group_id=5358
http://forums.codeblocks.org/index.php?topic=2958.0
Here's another interesting factoid that might work for a Linux GDB pgm console:
From "man xterm"
-Sccn This option allows xterm to be used as an input and output
channel for an existing program and is sometimes used in spe-
cialized applications. The option value specifies the last few
letters of the name of a pseudo-terminal to use in slave mode,
plus the number of the inherited file descriptor. If the
option contains a ``/'' character, that delimits the characters
used for the pseudo-terminal name from the file descriptor.
Otherwise, exactly two characters are used from the option for
the pseudo-terminal name, the remainder is the file descriptor.
Examples:
-S123/45
-Sab34
Note that xterm does not close any file descriptor which it did
not open for its own use. It is possible (though probably not
portable) to have an application which passes an open file
descriptor down to xterm past the initialization or the -S
option to a process running in the xterm.
And here it is in action:
(http://img256.imageshack.us/img256/885/131ma0.png)
The funny hex value is the slave xterm reporting its id.
Looks like debugger could start a slave xterm with the -S parameter.
References:
http://ccnuma.anu.edu.au/~wpc/blog/programming/pseudo-terminals.html
Ok, we almost got it. Here's how to create a console for a linux program running under GDB.
First, to do it by hand.
create a script named "oterm" with the following commands:
Make the script executable with: "chmod +x oterm"
From terminal A, issue the following commands:
- xterm -e ./oterm &
- gdb conio
- tty /dev/pts/# (where # is the result of the ps/# shown in xterm)"
- break main
- run
Step trough the code in terminal A and enter I/O in the xterm.
Gdb and the debuggee will run in terminal A while the debuggee input/output will be piped to the xterm.
(http://img62.imageshack.us/img62/4356/136oy3.png)
Now all we have to do is get CB linux gdb_driver to do the same thing.
//conio source
#include <iostream>
#include <cstdlib>
#include <cstring>
using namespace std;
int upstring(char *value);
int main()
{
char value[81]={'\0'};
int upper_count;
do
{ cout << "Please type in a String (max. 80 characters): ";
cin.getline(value, 80);
upper_count = upstring(value);
cout << upper_count << " characters are converted" << endl;
cout << "The new string is now: " << value << endl;
}while(upper_count);
return EXIT_SUCCESS;
}
int upstring(char *value)
{
int i=0;
while(*value)
{
if(islower(*value))
{
*value=toupper(*value);
i++;
}
value++;
}
return(i);
}
A ctrl-z and enter key will end the conio program.
The xterm sleep can be terminated with a ctrl-c.
CB will have to create the temporary script,
Create the Xterm with the script as -e arg and memorize its pid and terminal device name,
CB must issue the gdb "tty /dev/pts/#" command, then perform it's usual tasks.
CB will have to kill the pid on gdb exit.
Now all I have to do is figure out how CB can get the /dev/pts number.
Well finally, CodeBlocks on andLinux running a console program with an actual console under the gdb debugger.
(http://img122.imageshack.us/img122/2610/137px5.png)
Now I have to figure out where to kill the console once the pgm ends.
Also how to write to the debugger debug log instead of the debugger log.
m_pDBG->Log(wxString::Format( _("Executing: %s"), psCmd.c_str()) );
is evidently the wrong log.