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