From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 543E43858C52 for ; Sat, 4 Feb 2023 15:40:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 543E43858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675525248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aMaYuySuEO05EIQK33pVzYyWBLNzoFxXblhj+2j/kSw=; b=eimCpUbo1y/wzZjefsXqZNw5+0MY67c6KnSWi5B9oVaGfwrbtO/TPJ1dTScFdYMSrkdjN2 yk55ITR8a72RXcmASZwr53OvSHqUP8hSs2LawhwN36/sN+PnxLi6bG747b93GYnkTIikSy pNDCy5ZLKhVZO/+STvF8k33dCaYkeIA= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-104-pokvfobEPx-YD-hOjVlyXQ-1; Sat, 04 Feb 2023 10:40:46 -0500 X-MC-Unique: pokvfobEPx-YD-hOjVlyXQ-1 Received: by mail-qt1-f200.google.com with SMTP id z12-20020ac8710c000000b003b829a0eda2so4111392qto.21 for ; Sat, 04 Feb 2023 07:40:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aMaYuySuEO05EIQK33pVzYyWBLNzoFxXblhj+2j/kSw=; b=NMttMJA3ZvE54gR+R5w08OU9X32O0rUBlhj8U5z4gfR+BL5uLcj5SlkGi+nB9/6HBf 0XoD90hMZUJceLFZ6rDJPFWVqFhFbeA6+Mud+EcBhgPQMGKJfq0APvfYc6B+LrOY5fVV z5aMKkpB9mdFY1yKl1LtisEZh+Ao38JUqIp54GXEmmYS9/1CsIc9IzOcQvq/bzL2UiYS nhVkhkV2RQlIfP79ip3pdnnPD9+dQWlNjmtuR6GyJ+FyVQOXGGf16RSWp/N52bL7aaUv YqO7QTJGjovLI4pUTr+rYuDTWodRa6bu2TpXgUxF0PRcG504Oh5IiPOnM+1SUcSCdyZI kGdQ== X-Gm-Message-State: AO0yUKVpLqtcJCmKD8Kt2i/1qrsqYXOiwqYq8TThWEUyh9VGZIOfRa4j qBYwBBWhHTZIrOmtQRIoPjbVrcEoZu804eBzWPSusY093PaoM87wnGw9DcIuGarBXEsiO3nXdbZ GCon3KxINVbuhps6StXbldcPGaWRQ4fPDuODNOtXxmxZQ4aFtjbkI7a5kWftiRLIt5SuSDIN5Dw == X-Received: by 2002:ac8:7f01:0:b0:3b8:6075:5d12 with SMTP id f1-20020ac87f01000000b003b860755d12mr24475177qtk.54.1675525246089; Sat, 04 Feb 2023 07:40:46 -0800 (PST) X-Google-Smtp-Source: AK7set/5tUAj2viH/HfsvG1fAWV/GbnBnooofCQT3vijeoElkOJ484bT10nIDEQ+eJEzrBffC3mIGw== X-Received: by 2002:ac8:7f01:0:b0:3b8:6075:5d12 with SMTP id f1-20020ac87f01000000b003b860755d12mr24475143qtk.54.1675525245770; Sat, 04 Feb 2023 07:40:45 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id h17-20020ac85e11000000b003a5c6ad428asm3718324qtx.92.2023.02.04.07.40.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Feb 2023 07:40:45 -0800 (PST) From: Andrew Burgess To: Joel Brobecker via Gdb-patches , Andrew Burgess via Gdb-patches Cc: Pedro Alves , Joel Brobecker Subject: Re: [PATCHv2 4/6] gdb: error if 'thread' or 'task' keywords are overused In-Reply-To: References: <52913f3f-834b-dc13-1f15-9eef8db802e7@palves.net> <87mt5ur99u.fsf@redhat.com> Date: Sat, 04 Feb 2023 15:40:43 +0000 Message-ID: <878rhdqw04.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: Joel Brobecker via Gdb-patches writes: > 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! Thanks for the detailed write up. I'm going to keep the original patch as is for now, but will follow up with an additional patch that will give an error if a user tries to use 'task' and 'thread' in the same command. Thanks, Andrew