From: Ed Peschko <esp5@pge.com>
To: gdb@sourceware.org
Cc: esp5@pge.com
Subject: Re: tracing, attaching to gdb processes
Date: Wed, 15 Mar 2006 23:37:00 -0000 [thread overview]
Message-ID: <20060315231846.GA13847@mdssdev05> (raw)
In-Reply-To: <20060315142230.GA12258@nevyn.them.org>
On Wed, Mar 15, 2006 at 09:22:31AM -0500, Daniel Jacobowitz wrote:
> On Tue, Mar 14, 2006 at 08:16:18PM -0800, Ed Peschko wrote:
> > Also, I note that when you do do something like this, you get a 'press <return> to
> > coninue, q<return> to quit'. It would be nice if there was a way to override this.
>
> "set height 0"
>
> Stopping on input is a bit more complicated than you think. Whenever
> the program is running, it has control of the terminal - and input goes
> to it, not to us. I don't see an easy way to do this.
The way to do it is thorugh something similar to ReadKey - For example, the
following perl script does sort of what I'd want:
use Term::ReadKey;
ReadMode('cbreak');
while (1)
{
# do stuff.
if (defined($char = ReadKey(-1)))
{
last;
}
system("ls");
sleep(1);
}
At every point the program hits the ReadKey call, it checks to see if there is input to
process, and if so, drops out. If there is nothing to read, it continues. So you basically
will get a bunch of 'lses' until you hit anything, and then the program will stop.
Term::ReadKey is implemented with its own handwritten c, but I can't imagine that
readline wouldn't have something similar.
> > cool.. then simply add that as a hook inside the library. Which would
> > you rather write (continuously), the first one, or the second? And isn't it useful
> > to have it just for suggesting ideas to end users of gdb?
>
> That says to me that it belongs in the manual. Shipping a library is a
> serious pain; why should we do it for a two-line function?
Right now, I look inside of the gdb folder inside of the build directory for
gdb-6.3, and I see that make creates a:
libgdb.a
file. I'm assuming it wouldn't be that difficult to add there.
Another thing that might be useful to add there is an 'automatic breakpoint'
function. Perl has '$DB::single', ie: you set the value $DB::single = 1, the
debugger automatically stops. Similarly, it would be nice to have a
gdb_stop();
function, which you could use to pepper your code with useful breakpoints.
As far as patching goes, I'd be willing to write some of this stuff, if I got a pointer
to say, how you do a non-blocking read with readline. And maybe an inkling if
someone would be willing to include it in the 'standard distribution' (I'm not too
hot on needing to maintain a local patch)
Ed
next prev parent reply other threads:[~2006-03-15 23:18 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
2006-03-15 5:09 ` Ed Peschko
2006-03-15 14:23 ` Daniel Jacobowitz
2006-03-15 23:37 ` Ed Peschko [this message]
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=20060315231846.GA13847@mdssdev05 \
--to=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