Console for Linux GDB program input/output

[Pecan]

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:




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



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.


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".

Code

#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:

Code

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.



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

[Pecan]

Here's another interesting factoid that might work for a Linux GDB pgm console:

From "man xterm"

Code

       -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:

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

[Pecan]

Attached is a program (xslave) that when run under gdb will read and write to a slave xterm.

I don't entirely understand how it works, and I've hacked on it until it runs under andLinux. But have a run with it.

The author explains:

After much fiddling and thinking, I realised that what I wanted to do with the pseudo-terminal is different to most examples of it: I wanted to give the master to the child program, not the slave: I wanted the child to be the user input and the parent to simply be a proxy between the user and the simulated program (going back to the original simulation IO problem). So after simply switching slave and master, the program worked as expected.

References:
http://ccnuma.anu.edu.au/~wpc/blog/programming/pseudo-terminals.html

[attachment deleted by admin]

[Pecan]

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:

• ps
• sleep 600000

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.
 



Now all we have to do is get CB linux gdb_driver to do the same thing.

Code

//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.

[Pecan]

Well finally, CodeBlocks on andLinux running a console program with an actual console under the gdb debugger.



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.

Code

 m_pDBG->Log(wxString::Format( _("Executing: %s"), psCmd.c_str()) );

is evidently the wrong log.

[Pecan]

Patch 1882 has been submitted to provide a debugging console for Linux.

The user should also apply patch 1881 to stop the crashes when killing the program with the stop button.

References:
http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1882&group_id=5358
Debugging Console for Linux
http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1881&group_id=5358
Fix for Debugger termination crashes
http://developer.berlios.de/bugs/?func=detailbug&bug_id=7336&group_id=5358
LINUX: input when debugging console application