This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tracing, attaching to gdb processes


> > I don't understand..
> > 
> > Are you suggesting that I make an expect script to control gdb, and then have
> > that control script pass characters to the underlying process? Or something
> > more exotic?
> 
> The GDB CLI scripting language has "while".  See the manual.
> 
> It won't work very well though.  The C-c will stop the sleep, but not
> the while.

exactly...

> > And why can't this be built into gdb in the form of a 'set' variable?  Either that,
> > or a built-in high-resolution 'sleep' call that doesn't require spawning a shell?
> 
> You asked if GDB could do what you wanted; this is how it can.  I
> don't know whether it should have a built in command to do this or not.
> 
> > Or best yet, a builtin non-blocking read call that waits for a person's input?
> 
> I fail to see how this relates to what you wanted.

while 1;
> set end_on_input
> step;
> gdb_sleep .1

'set stop_on_input' would make it so that the user could interrupt the script with
the press of a key via a non-blocking read.. ie: exactly what I would want. 
gdb_sleep would be a high res sleep call that slept fractional amounts of a second.

Also, I note that when you do do something like this, you get a 'press <return> to
coninue, q<return> to quit'. It would be nice if there was a way to override this.


> > It would be very cool, for example, if you could somehow trigger gdb to run with
> > an instantiated call, say:
> > 
> > /* my code here */
> > spawn_gdb()
> > /* my code here */
> > 
> > and then a gdb would be spawned automatically and attached to the process at the
> > point right following the spawn_gdb call. 
> 
> GDK/GTK already have code to do this.  So do lots of other libraries. 
> It's not something that needs to be distributed with GDB; it's just
>   if (fork () == 0)
>     execlp ("gdb", argv[0], getppid (), NULL);

well, cool.. then simply add that as a hook inside the library. Which would 
you rather write (continuously), the first one, or the second? And isn't it useful
to have it just for suggesting ideas to end users of gdb?

Anyways, if this isn't the place to request gdb features, what *is* the correct
place?

Ed


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]