Re: tracing, attaching to gdb processes

[Daniel Jacobowitz <drow@false.org>]

On Wed, Mar 15, 2006 at 07:00:13PM -0800, Ed Peschko wrote:
> In any there could be a variable (call it set no_block_read) which toggles
> it so that the user sends input to gdb rather than the underlying program.

You might want to play around with Unix process groups and shared
stdin; it doesn't work quite like you think it does.

I'm sure there's some way to do this, but I don't know how.

> > Feel free:
> > 
> > void gdb_stop (void) { }
> > 
> > (gdb) break gdb_stop
> > 
> > Or put it in a .gdbinit file that you ship with the application.
> 
> Or a hook could be put into gdb which automatically inserts a breakpoint 
> on the function name 'gdb_stop' if it exists.

"break gdb_stop" at the end of your .gdbinit file will do this.

> I mean, think of what happens if gdb_stop is defined in a place which is 
> dynamically loaded? Then the users' setting of the breakpoint will fail.
> Having gdb check upon loading a symbol for the gdb_stop function makes 
> it much easier.
> 
> And even if the functionality for delayed breakpoints is added to gdb, it still
> is forcing the user to reimplement something for each project he/she works
> on..

GDB already has delayed breakpoints (the term used is "pending").  And
it doesn't require any reimplementation if you put it in
$HOME/.gdbinit.

You might want to spend some time with the existing manual.  It's very
complete, and it seems like you don't realize a lot of the things GDB
is already capable of.

You've definitely suggested a couple of things that the manual doesn't
make clear, and I'm saving your messages to add to the manual as
suggestions at some point.

-- 
Daniel Jacobowitz
CodeSourcery