Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Piet/Pete Delaney <piet@sgi.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: Piet Delaney <piet@sgi.com>, gdb@sources.redhat.com
Subject: Re: Debugging gdb with gdb
Date: Mon, 04 Feb 2002 15:13:00 -0000	[thread overview]
Message-ID: <20020204151313.B18969@sgi.com> (raw)
In-Reply-To: <20020204150044.A18969@sgi.com>

On Mon, Feb 04, 2002 at 03:00:44PM -0800, Piet/Pete Delaney wrote:
> On Mon, Feb 04, 2002 at 03:01:27PM -0700, Kevin Buettner wrote:
> > On Feb 4, 12:23pm, Piet/Pete Delaney wrote:

I think I could likely remove the target cmd from the cmds in the tmp file,
print the name of the pty, and then target it myself from gdb prompt. I suppose
that's what you may have been suggeting.

-piet

> > 
> > > Happen to have a trick to get the inferior GDB to wait for the attaching GDB
> > > to place breakpoints prior to the inferior setting up a remote debug session.
> > > skdb starts the inferior gdb with a named pipe (see attached), I'm thinking 
> > > about adding a loop to spin till a global variable is set by the attaching
> > > gdb to indicate that the inferionr gdb can progress with setting up the 
> > > remote connections and sent the 'g' packet.
> > 
> > I don't understand why you need to do this.  Why not just start up the
> > inferior gdb first and attach to it with another gdb while it's at the
> > prompt?  Once you're attached, you can set breakpoints wherever you
> > like.  After your breakpoints are set, do a ``continue'' and then
> > start entering your target connection commands in the inferior gdb.
> > Assuming you've placed a breakpoint somewhere along the execution path
> > that the inferior gdb will take when/after it connects, you'll be
> > stopped...
> 
> skdb starts gdb with the -x option so that gdb will get cmds from a tmp file. The cmds
> targets the remote to a pty. I suppose I could disable the startup code. Adding a hang 
> in gdb seems easier.  Likely I'll add an option to the inferior gdb and enable the switch 
> to hang before sending the 'g' packet and pass the new option via the execvp() args to gdb.
> The new option might come in handy for other bugs.
> ----------------------------------------------------------------------------------------------------
> 
> 				stdin/stdout
> 				    |
> 				    |
> 				    |
> 				    ^
> 				   / \ 
> 				  /   \ 
> 				 /     \ 
> 				/       \ 
> 			       /         \ 
> 			      /           \ (ignored)
> 		+---------------+  pty	+---------------+     telet	+---------------+
> 		+	gdb	+ <--->	+	skdb	+  <--------->	+	kdb	+
> 		+		+	+		+		+		+
> 		+---------------+	+---------------+		+---------------+
> 			|			|
> 			\			/
> 			 \		       /
> 			  \		      /
> 				/tmp/tmpnam:
> 				
> 		
> 				
> ----------------------------------------------------------------------------------------------------
> /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\
>  * Function: pfork
>  *    Create a master/slave pty pair, fork and exec gdb with
>  *    -x fudged to point it to the slave pty in the parent
>  *    process space. Child will do the real work.
>  * Parameters:
>  *    argc - number of gdb command line parameters
>  *    args - gdb's command line parameters
>  * Returns:
>  *    file descriptor for master PTY on success or -1 on error
> \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
> int
> pfork (int argc, char ** args)
> {
>     int pt;
> 
>     if ( (pt = open ("/dev/ptmx", O_RDWR)) >= 0 ) {
>         if ( grantpt (pt) != -1 ) {
>             if ( unlockpt (pt) != -1 ) {
>                 FILE * tf;
>                 char * tname = strdup (tmpnam (NULL));
>                 pid_t child;
> 
>                 if ( tname == NULL ) {
>                     puts ("Oops!");
>                     return -1;
>                 } else if ( (tf = fopen (tname, "w")) == NULL ) {
>                     perror (tname);
>                     free (tname);
>                     return -1;
>                 }
> 
>                 fprintf (tf,
>                          "shell rm %s\n"
>                          "set remotedebug %d\n"
>                          "set serialdebug %d\n"
>                          "target remote %s\n"
>                          "define lsmod\n"
>                          "set $mod = (struct module*)module_list\n"
>                          "while $mod != &kernel_module\n"
>                          "printf \"%%p\t%%s\\n\", (long)$mod, ($mod)->name\n"
>                          "set $mod = $mod->next\n"
>                          "end\nend\n",
>                          tname,
>                          ((debug & SKDB_DBG_REMOTE) != 0),
>                          ((debug & SKDB_DBG_SERIAL) != 0),
>                          ptsname(pt));
>                 fflush (tf);
> 
>                 if ( (child = fork ()) > 0 ) {
>                     int i;
>                     char **gargs = calloc (argc+5, sizeof (char *));
>                     if ( gargs == NULL ) {
>                         kill (child, SIGTERM);
>                         exit (1);
>                     } else {
>                         gargs[0] = "gdb";
>                         gargs[1] = "-q";
>                         gargs[2] = "-x";
>                         gargs[3] = tname;
> 
>                         close (pt);
> 
>                         for ( i=0; i < argc ; i++ ) {
>                             gargs[i+4] = args[i];
>                         }
> 
>                         gargs[i+4] = NULL;
> 
>                         execvp ("gdb", gargs);
>                         kill (child, SIGTERM);
>                         exit (1);
>                     }
>                     /*NOTREACHED*/
>                 } else if ( child < 0 ) {
>                     perror ("fork");
>                     close (pt);
>                     pt = -1;
>                 }
> 
>                 fclose (tf);
> 
>                 free (tname);
>                 return (pt);
>             } else {
>                 perror ("unlockpt");
>             }
>         } else {
>             perror ("grantpt");
>         }
>         close (pt);
>     }
> 
>    return (-1);
> }
> -----------------------------------------------------------------------------------------------------
> 
> -piet


  reply	other threads:[~2002-02-04 23:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-01  8:25 Salman Khilji
2002-02-01  9:26 ` Daniel Jacobowitz
2002-02-03 12:29 ` Joel Brobecker
2002-02-04  1:32   ` Christophe PLANAT
2002-02-04 12:24   ` Piet/Pete Delaney
2002-02-04 14:02     ` Kevin Buettner
2002-02-04 15:00       ` Piet/Pete Delaney
2002-02-04 15:13         ` Piet/Pete Delaney [this message]
2002-11-14  6:13 Debugging GDB with GDB James Sampson
2002-11-14  6:58 ` Tim Combs
2002-11-15  0:51 James Sampson
2006-08-31 16:17 Rajesh Warange
2006-08-31 16:34 ` Daniel Jacobowitz
2006-08-31 17:43 ` Michael Snyder
2006-08-31 21:24   ` Andreas Schwab
2006-08-31 22:54     ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020204151313.B18969@sgi.com \
    --to=piet@sgi.com \
    --cc=gdb@sources.redhat.com \
    --cc=kevinb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox