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:00:00 -0000 [thread overview]
Message-ID: <20020204150044.A18969@sgi.com> (raw)
In-Reply-To: <1020204220127.ZM18381@localhost.localdomain>
On Mon, Feb 04, 2002 at 03:01:27PM -0700, Kevin Buettner wrote:
> On Feb 4, 12:23pm, Piet/Pete Delaney wrote:
>
> > 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
next prev parent reply other threads:[~2002-02-04 23:00 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 [this message]
2002-02-04 15:13 ` Piet/Pete Delaney
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=20020204150044.A18969@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