changing gdb's behaviour on breakpoints

changing gdb's behaviour on breakpoints

[ranjith kumar]

Hi all,

1)  We know that when the program( being debugged by gdb) hits a
breakpoint, the execution of the program
        will be   stopped and gdb will displays a message like

"  Breakpoint 2829, process_event () at event-loop.c:298
    298	  if (check_async_ready ())
   (top-gdb)  "

and gdb waits for input from the user.

Is is possible to change this behaviour?
I want gdb to just display the message, but not to wait for the input
from the user, and must continue the
  program automatically.

2) I have gdb's sorce code. Which function of gdb's source code will
be called when the program hits a brakpoint?
 Which function of gdb's source code will be called when gdb continues
the program?

3) By the way is the 'gdb' single threaded program? If not please tell
me when it will create other threads?

Thanks in advance.

Re: changing gdb's behaviour on breakpoints

[Jan Kratochvil]

On Sun, 15 Nov 2009 19:45:30 +0100, ranjith kumar wrote:
> 1)  We know that when the program( being debugged by gdb) hits a
> breakpoint, the execution of the program
>         will be   stopped and gdb will displays a message like
> 
> "  Breakpoint 2829, process_event () at event-loop.c:298
>     298	  if (check_async_ready ())
>    (top-gdb)  "
> 
> and gdb waits for input from the user.
> 
> Is is possible to change this behaviour?
> I want gdb to just display the message, but not to wait for the input
> from the user, and must continue the
>   program automatically.
+
> 2) I have gdb's sorce code. Which function of gdb's source code will
> be called when the program hits a brakpoint?
>  Which function of gdb's source code will be called when gdb continues
> the program?

Yes, see:
$ info '(gdb)Break Commands'


> 3) By the way is the 'gdb' single threaded program? If not please tell
> me when it will create other threads?

gdb itself it singlethreaded but it handles multithreaded debuggees fine.

Getting gdb itself multithreaded could bring better performance on multicore
hosts in some cases but it will bring no new functionality.  Making gdb itself
multithreaded has various blockers due to its internal infrastructure.


Regards,
Jan