Re: tracing, attaching to gdb processes

[Daniel Jacobowitz <drow@false.org>]

On Wed, Mar 15, 2006 at 03:18:46PM -0800, Ed Peschko wrote:
> On Wed, Mar 15, 2006 at 09:22:31AM -0500, Daniel Jacobowitz wrote:
> > 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:

No, sorry, you did not understand my explanation of the problem.  The
program being run is usually on the same terminal as GDB.  If it reads, it
will consume the input.

> 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. 

No; that library is only used in the creation of GDB, it should never
be linked to anything but GDB.  It's just a convenience during the
build process.  Once upon a time there were experiments with linking
things to GDB directly; eventually we decided that controlling it
through a pipe was a better choice.

> 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. 

Feel free:

void gdb_stop (void) { }

(gdb) break gdb_stop

Or put it in a .gdbinit file that you ship with the application.

-- 
Daniel Jacobowitz
CodeSourcery