From: Daniel Jacobowitz <drow@false.org>
To: Ed Peschko <esp5@pge.com>
Cc: gdb@sourceware.org
Subject: Re: tracing, attaching to gdb processes
Date: Wed, 15 Mar 2006 03:45:00 -0000 [thread overview]
Message-ID: <20060315034420.GA1616@nevyn.them.org> (raw)
In-Reply-To: <20060315030437.GE10146@mdssdev05>
On Tue, Mar 14, 2006 at 07:04:37PM -0800, Ed Peschko wrote:
> > In general, you can get this by having a loop that does "while 1; step;
> > shell sleep 1" and hitting Control-C to stop it. Anything more
> > complicated than that involves the "hitting a button to stop" concept,
> > which means a GUI should be issuing the step commands - that's easy
> > to do when you're driving GDB.
>
> I don't understand..
>
> Are you suggesting that I make an expect script to control gdb, and then have
> that control script pass characters to the underlying process? Or something
> more exotic?
The GDB CLI scripting language has "while". See the manual.
It won't work very well though. The C-c will stop the sleep, but not
the while.
> And why can't this be built into gdb in the form of a 'set' variable? Either that,
> or a built-in high-resolution 'sleep' call that doesn't require spawning a shell?
You asked if GDB could do what you wanted; this is how it can. I
don't know whether it should have a built in command to do this or not.
> Or best yet, a builtin non-blocking read call that waits for a person's input?
I fail to see how this relates to what you wanted.
> well, I was thinking of something like gdbserver (which I wasn't aware existed)
> but now I see what people were talking about when they were saying 'use screen
> with your gdb processes' - I wasn't aware that screen could be started already
> detached, nor that you could run an alternate shell with screen (eg: 'gdb').
>
> Anyways, maybe this warrants an entry in the manual - its not only valgrind that
> could benefit from this workflow, but other processes, especially those run
> through inetd.
Maybe.
> It would be very cool, for example, if you could somehow trigger gdb to run with
> an instantiated call, say:
>
> /* my code here */
> spawn_gdb()
> /* my code here */
>
> and then a gdb would be spawned automatically and attached to the process at the
> point right following the spawn_gdb call.
GDK/GTK already have code to do this. So do lots of other libraries.
It's not something that needs to be distributed with GDB; it's just
if (fork () == 0)
execlp ("gdb", argv[0], getppid (), NULL);
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-03-15 3:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-06 5:28 Ed Peschko
2006-03-06 11:55 ` Bob Rossi
2006-03-06 12:01 ` Dave Korn
2006-03-06 20:10 ` Ed Peschko
2006-03-14 2:28 ` Daniel Jacobowitz
2006-03-15 3:44 ` Ed Peschko
2006-03-15 3:45 ` Daniel Jacobowitz [this message]
2006-03-15 5:09 ` Ed Peschko
2006-03-15 14:23 ` Daniel Jacobowitz
2006-03-15 23:37 ` Ed Peschko
2006-03-16 0:53 ` Daniel Jacobowitz
2006-03-16 3:08 ` Ed Peschko
2006-03-16 7:04 ` Daniel Jacobowitz
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=20060315034420.GA1616@nevyn.them.org \
--to=drow@false.org \
--cc=esp5@pge.com \
--cc=gdb@sourceware.org \
/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