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


On Tue, Mar 14, 2006 at 07:04:37PM -0800, Ed Peschko wrote:
> > In general, you can get this by having a loop that does "while 1; step;
> > shell sleep 1" and hitting Control-C to stop it.  Anything more
> > complicated than that involves the "hitting a button to stop" concept,
> > which means a GUI should be issuing the step commands - that's easy
> > to do when you're driving GDB.
> 
> 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.

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

> well, I was thinking of something like gdbserver (which I wasn't aware existed) 
> but now I see what people were talking about when they were saying 'use screen
> with your gdb processes' - I wasn't aware that screen could be started already
> detached, nor that you could run an alternate shell with screen (eg: 'gdb').
> 
> Anyways, maybe this warrants an entry in the manual - its not only valgrind that 
> could benefit from this workflow, but other processes, especially those run
> through inetd. 

Maybe.

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

-- 
Daniel Jacobowitz
CodeSourcery


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