This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Thread-specific breakpoints
- From: Fabian Cenedese <Cenedese at indel dot ch>
- To: gdb at sources dot redhat dot com
- Date: Wed, 18 Aug 2004 13:57:26 +0200
- Subject: Re: Thread-specific breakpoints
Hmpf, sorry for the private mail. Now also to the list.
>> Yes, that's along the lines I was thinking. And after intense looking I even
>> found it in the manual. I missed it the first time as the break command
>> is explained in 5.1.1 whereas break <location> thread <number> by itself
>> is in 5.4.
>>
>> After looking at the communication with the stub it seems that the Z0
>> packet only informs the stub about a breakpoint but not about the thread.
>> So every thread will stop here and gdb needs to tell them to continue
>> it it's not the wanted one. That could generate quite a lot of communication
>> (important if it's a serial connection) and also changes the timing quite
>> a lot. If the breakpoint handling was in the stub the stop'n'go could be
>> made much faster without the interaction of gdb. I guess if there is no
>> other possibility I could use the "monitor" command to inform the stub
>> about the thread of the breakpoint. But then again this is difficult as the
>> breakpoints are only set once a "step" or "continue" is sent...
>>
>> Thanks for the help anyway
>
>Yes, there's no way to set remote-assisted thread-specific breakpoints
>in the remote protocol. This might be a good thing to add.
What about reading them back? Our embedded system is "intelligent"
(yeah, I know) and has its own breakpoint handling for various reasons
(performance, usability, security if the debugger dies...). So if we attach
to a running target we first read the available breakpoints from the system.
I think this is not only missing in the protocol but in gdb in general.
Thanks
bye Fabi