Thread-specific breakpoints

Thread-specific breakpoints

[Fabian Cenedese]

Hi

Is there support for thread-specific breakpoints in gdb? I couldn't see it
in the interface/commands. If not, are there plans to add it to gdb?

I know that other people have already tried to do so, e.g. SmartGDB
http://hegel.ittc.ukans.edu/projects/smartgdb/brief.html

But this a workaround with the help of tcl and only supports some
thread libs. As I need support over a stub for a proprietary system
(not Linux) this won't work.

Thanks

bye  Fabi

Re: Thread-specific breakpoints

[Daniel Jacobowitz]

On Mon, Aug 16, 2004 at 09:19:01AM +0200, Fabian Cenedese wrote:
> Hi
> 
> Is there support for thread-specific breakpoints in gdb? I couldn't see it
> in the interface/commands. If not, are there plans to add it to gdb?
> 
> I know that other people have already tried to do so, e.g. SmartGDB
> http://hegel.ittc.ukans.edu/projects/smartgdb/brief.html
> 
> But this a workaround with the help of tcl and only supports some
> thread libs. As I need support over a stub for a proprietary system
> (not Linux) this won't work.

What features do you need from thread-specific breakpoints?  It could
mean several things.

The closest GDB comes is "break <location> thread <number>".

-- 
Daniel Jacobowitz

Re: Thread-specific breakpoints

[Fabian Cenedese]

>> Is there support for thread-specific breakpoints in gdb? I couldn't see it
>> in the interface/commands. If not, are there plans to add it to gdb?
>> 
>> I know that other people have already tried to do so, e.g. SmartGDB
>> http://hegel.ittc.ukans.edu/projects/smartgdb/brief.html
>> 
>> But this a workaround with the help of tcl and only supports some
>> thread libs. As I need support over a stub for a proprietary system
>> (not Linux) this won't work.
>
>What features do you need from thread-specific breakpoints?  It could
>mean several things.
>
>The closest GDB comes is "break <location> thread <number>".

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

bye  Fabi

Re: Thread-specific breakpoints

[Daniel Jacobowitz]

On Mon, Aug 16, 2004 at 04:20:39PM +0200, Fabian Cenedese wrote:
> 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.

-- 
Daniel Jacobowitz

Re: Thread-specific breakpoints

[Eli Zaretskii]

> Date: Mon, 16 Aug 2004 16:20:39 +0200
> From: Fabian Cenedese <Cenedese@indel.ch>
> >
> >The closest GDB comes is "break <location> thread <number>".
> 
> 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.

The `i' (Info-index) command is your friend.  In an Info browser, type
"i thread<TAB>" and you will be presented with a list of
thread-related index entries that are recorded in the manual.  Through
sheer luck (or maybe something else ;-), the very first entry is
exactly what you wanted.

Re: Thread-specific breakpoints

[Fabian Cenedese]

At 15:30 16.08.2004 -0400, Eli Zaretskii wrote:
>> Date: Mon, 16 Aug 2004 16:20:39 +0200
>> From: Fabian Cenedese <Cenedese@indel.ch>
>> >
>> >The closest GDB comes is "break <location> thread <number>".
>> 
>> 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.
>
>The `i' (Info-index) command is your friend.  In an Info browser, type
>"i thread<TAB>" and you will be presented with a list of
>thread-related index entries that are recorded in the manual.  Through
>sheer luck (or maybe something else ;-), the very first entry is
>exactly what you wanted.

Did I mention that I work on Windows? Does the info browser exist there
as well? I'll see if I find something. The printout of the manual is also
quite helpful, you can use a marker :) But of course searching is...
manually :)

Thanks

bye  Fabi  

Re: Thread-specific breakpoints

[Eli Zaretskii]

> Date: Tue, 17 Aug 2004 10:06:56 +0200
> From: Fabian Cenedese <Cenedese@indel.ch>
> 
> Did I mention that I work on Windows? Does the info browser exist there
> as well?

Texinfo was ported to Windows, although I once tried to use the
stand-alone Info reader from one such port and couldn't get anything
except "This terminal is too dumb" message.  But there's always the
Info reader built into Emacs (and that port does work on Windows).

Re: Thread-specific breakpoints

[Fabian Cenedese]

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

Re: Thread-specific breakpoints

[Paul Breed]

The remote protocol has...

Hct… -- set thread

Set thread for subsequent operations (m, M, g, G, et.al.). c depends on the 
operation to be performed: it should be c for step and continue operations, 
g for other operations. The thread designator t… may be -1, meaning all the 
threads, a thread number, or zero which means pick any thread.

Reply:

OK

for success
ENN

for an error


Paul

Re: Thread-specific breakpoints

[Fabian Cenedese]

>The remote protocol has...
>
>Hct… -- set thread
>
>Set thread for subsequent operations (m, M, g, G, et.al.). c depends on the operation to be performed: it should be c for step and continue operations, g for other operations. The thread designator t… may be -1, meaning all the threads, a thread number, or zero which means pick any thread.

That might work but also means a lot of overhead as this is a complete
thread switch which will read all registers and other thread specific info.
It might be necessary to do the breakpoint handling in another program
and just use the symbol lookup of gdb. But I'll see when I get there.

Thanks

bye   Fabi