From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 9C6943858C52 for ; Sat, 4 Feb 2023 05:52:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C6943858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-wr1-x42f.google.com with SMTP id m14so6272602wrg.13 for ; Fri, 03 Feb 2023 21:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Dci2/Q+UcYdPjvSS9tiH4+MrqjGXZ+v9pz2bV1fEcX4=; b=CGIgzBnkW2o3jp91i2FaPNKddLYm9mLGb1z0crDSpx7jnt/p9RcWQJzHTBEqXTRQjF YYRntwNCcRkAHstRRheLAHUCqZFTgTVNqANRu09Pw6dkatD8VOrX/KMWvjWa7hRpqMmm X5zqNjEZUXOKrWhLeOlEj3w73XImI1UG9QktnfgxgywG3c5D84/2krUzNGVf4wgS2Woe emvLH1zLe41SEW6kHSXV6hz2rTGcOWShfYSvDE9zCMq83vRAVo4c9gd7Mr+9OZEm4j3R lWzhgP2CoKmfmYbZrEiwwM7VAlCtTioB7kw5d8nIITilS6NIG0n+c3uZzfYcP3O3waqZ Kb7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Dci2/Q+UcYdPjvSS9tiH4+MrqjGXZ+v9pz2bV1fEcX4=; b=G3yWq+3qTANcIFoqBG2ORhkz7mor4B7IsO1vewTZYVar4RJj7fqrop6NwIFKgHPrU0 LKRBkY3gAGGYPCvV9ADz39YPWG+sYDSbKa9C4AEsZ4dfZZbilDfLFjVVjx4bUjjarV3K F22oJS/l18IsMzkjtBjiT/w+c/7Q9fl6Fg4NJvwPJfzfnix4hJFDAuBXIHAzxOtArFx5 LlX2w/TBd4tiKs8RYRwqsZUDcWDUDoHgiNW/xTa/ZfQBdvuITLtEN7cZGEuY5RRVungx I1hPenjK9Fr9eSHVqq7DuvYFDFwRPj9M3HE+MWEnjkNM1wNdMwUFpAKg+njndq4iLP1k /YMw== X-Gm-Message-State: AO0yUKUryvMoXWe358cxzWGXC6FV5688+HySA5Ka4BPhtgk+5/Yd7o9C V/Y816xbZMfMDl6YiITqrJXoYVS0kgNbr6icvg== X-Google-Smtp-Source: AK7set+3A86NBfjFx9zFSwHxeCYS/Ol6s35vzjQ5i2sSEYzge1uQHjI6MOHu7EAJjrmmBChG94pwKg== X-Received: by 2002:adf:f085:0:b0:2c3:db87:977c with SMTP id n5-20020adff085000000b002c3db87977cmr1664546wro.12.1675489953098; Fri, 03 Feb 2023 21:52:33 -0800 (PST) Received: from takamaka.gnat.com ([2a01:cb22:1d5:1100:8e0d:ded2:3479:536b]) by smtp.gmail.com with ESMTPSA id v1-20020adf8b41000000b002be505ab59asm3684114wra.97.2023.02.03.21.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 21:52:32 -0800 (PST) Received: by takamaka.gnat.com (Postfix, from userid 1000) id 493EC8224B; Sat, 4 Feb 2023 09:52:30 +0400 (+04) Date: Sat, 4 Feb 2023 09:52:30 +0400 From: Joel Brobecker To: Andrew Burgess via Gdb-patches Cc: Pedro Alves , Joel Brobecker Subject: Re: [PATCHv2 4/6] gdb: error if 'thread' or 'task' keywords are overused Message-ID: References: <52913f3f-834b-dc13-1f15-9eef8db802e7@palves.net> <87mt5ur99u.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mt5ur99u.fsf@redhat.com> X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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