This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tracing, attaching to gdb processes


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]