This is the mail archive of the gdb@sources.redhat.com 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: Thread-specific breakpoints


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



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