Re: tracing, attaching to gdb processes

[Ed Peschko <esp5 at pge dot com>]

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