aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2022-11-09 12:54:55 +0000
committerAndrew Burgess <aburgess@redhat.com>2023-02-06 11:02:48 +0000
commit980dbf36225150bf2558e5eda5f8c374adfe1323 (patch)
tree471e36b6b1860e4b475d490e63b53bfb203d28d0 /include
parentd4a8b80189c3fdb9d041583e576315a7306a2279 (diff)
downloadgdb-980dbf36225150bf2558e5eda5f8c374adfe1323.zip
gdb-980dbf36225150bf2558e5eda5f8c374adfe1323.tar.gz
gdb-980dbf36225150bf2558e5eda5f8c374adfe1323.tar.bz2
gdb: error if 'thread' or 'task' keywords are overused
When creating a breakpoint or watchpoint, the 'thread' and 'task' keywords can be used to create a thread or task specific breakpoint or watchpoint. Currently, a thread or task specific breakpoint can only apply for a single thread or task, if multiple threads or tasks are specified when creating the breakpoint (or watchpoint), then the last specified id will be used. The exception to the above is that when the 'thread' keyword is used during the creation of a watchpoint, GDB will give an error if 'thread' is given more than once. In this commit I propose making this behaviour consistent, if the 'thread' or 'task' keywords are used more than once when creating either a breakpoint or watchpoint, then GDB will give an error. I haven't updated the manual, we don't explicitly say that these keywords can be repeated, and (to me), given the keyword takes a single id, I don't think it makes much sense to repeat the keyword. As such, I see this more as adding a missing error to GDB, rather than making some big change. However, I have added an entry to the NEWS file as I guess it is possible that some people might hit this new error with an existing (I claim, badly written) GDB script. I've added some new tests to check for the new error. Just one test needed updating, gdb.linespec/keywords.exp, this test did use the 'thread' keyword twice, and expected the breakpoint to be created. Looking at what this test was for though, it was checking the use of '-force-condition', and I don't think that being able to repeat 'thread' was actually a critical part of this test. As such, I've updated this test to expect the error when 'thread' is repeated.
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions