This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: tracing, attaching to gdb processes
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