Re: tracing, attaching to gdb processes

Ed Peschko
2006-03-16T03:00:24Z

On Wed, Mar 15, 2006 at 06:37:39PM -0500, Daniel Jacobowitz wrote:
> 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.

Ok, that's fine, I get what you are saying now.

But its really punishing 99% of the programs out there for the requirements of
the remaining 1%. Either they ignore stdin altogether, or take a bunch of
stdin input and go into 'processing' mode, after which they don't need to touch
stdin.

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.

Then the user would type:

(gdb) set no_block_read=qq
(gdb) while 1;
> step
> db_sleep .1
> end

and now if users input the string 'qq' it would cause the label to stop.

In fact you could be really fancy about it - namely, if a process *was*
expecting stdin, that the no_block_read would continue until it got
input from stdin, which it would then compare against whatever was
listed in 'no_block_read'. Example:

.... strings of input ... *user presses 'qq'.
... strings of input ... gets fed to program, qq stops loop, and
the input qq gets discarded.

Of course this slows down the feeding of input, but it wouldn't be the default
so that would be fine.. And I'd think it would be relatively easy to implement
because you have to toggle between input streams anyways so people can
enter commands to gdb.

And finally IMO the current behaviour is broken. As you yourself stated,
having an infinite loop in scripting is basically useless.

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

I'd put it the docs then.

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

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

Ed