[PATCHv2 4/6] gdb: error if 'thread' or 'task' keywords are overused

[Joel Brobecker]

Hi Andrew,

> > On 2023-01-20 9:46 a.m., Andrew Burgess via Gdb-patches wrote:
> >> 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.
> >
> > The patch looks fine, but does it make sense to allow both thread and task
> > at the same time?
> 
> I don't know enough about Ada tasks to comment here.  If someone who
> knows can say categorically that threads and tasks can't coexist than
> I'd be happy to add a patch to prevent them being used together.

Pedro raises a good question!

At the language level, I don't think there is anything that says
that Ada tasks can't be implemented independently of threads.
In fact, on baremetal targets, that's what we have to do, since
we don't have an underlying thread layer.

With that said, for GDB itself, the implementation of the ada tasking
layer is done on top of the GDB's thread layer. In simple terms,
what the ada-task.c module does is simply translating Ada task IDs
into thread ptid-s. So, when we say "switch to task X", or "break on
task X", internally, it essentially translates "task X" into "thread Y".

Based on this implementation, it is always suspicious if someone
uses both a thread ID and a task ID in the same command (or I would
view those as "additive", but that's not the direction taken by
your patch series). I would therefore indeed raise an error if
both are used in the same command.

One side note about the baremetal platforms, since I mentioned them:
While the platform itself doesn't provide threads [1], you might ask
yourself how the Ada tasking layer might be implemented. This is where
the ravenscar-thread layer kicks in. It actually relies on the Ada
runtime to determine the list of tasks that exists, and constructs
a list of threads from that data, thus providing the threads that
the ada-task module needs to function.

[1] On baremetal target, we've seen multicore system report each CPU
    as a thread. That's what QEMU does, for instance.

I hope this helps!
-- 
Joel