From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id pfnrBkcCPGpzeRYAWB0awg (envelope-from ) for ; Wed, 24 Jun 2026 12:13:59 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=ijvyc55o; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0E8101E024; Wed, 24 Jun 2026 12:13:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id F036C1E024 for ; Wed, 24 Jun 2026 12:13:56 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 72FAD4BA543C for ; Wed, 24 Jun 2026 16:13:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 72FAD4BA543C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1782317635; bh=Jd4PxTezgu22Dhpb7H7V7AiulDdRU6rhfSqzuxbdYWs=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=ijvyc55oyWTpExkq/4SoY+DsJHugjcYvUIIJe8LXvS4X4ngDKZuN6cln5eAch7g0f EVwbZ6h3/s55CJxVY47TcMs2wsbrUhU897hMsj1yPoFOwW0Mg000LFir64KJsVyhvM Yx/MNCOj7xALIYVgyBkCH6GUarjRSZHtfHAIc0YY= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 73F2F4BA543C for ; Wed, 24 Jun 2026 16:13:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 73F2F4BA543C ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 73F2F4BA543C ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782317599; cv=none; b=qVf6qxbKdCfRakv38EX87QpiBkXWItFtGw97U44GrsEBDhMWWyAuyS2Th5zZ7ZCZM5Zp3/8xeeFIW3BYD5cmZLrOllMN5mS5iPPNv7JvMhscfAWYu8bHJuSlArNF3+QWxkMaP5pdGodWYRYJIP4/rY1qdYbGJHpoSxcjw2ExdKw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782317599; c=relaxed/simple; bh=hPewVfVPaa6J0Hzavz1fNEH0Ykhyf5j5zw6tX4Gtbh0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Veft+6VHH0//rf3X2VSoatWcjMblNlNfnpRn+WxIKGRcLJFQjfklqkq4nMGAZVVcQvZreouxvkkEt8rByR5IABxbUpsBCi0mSUscAlfQDeE78CHOytP7FqWAy4RbM7wRHWZIlxYUYux3RApcF/y+HF+JEROznORBa774sMcljQI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KBOCECXg DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73F2F4BA543C Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-yb8WBD7NOKuYO7NAUugRFA-1; Wed, 24 Jun 2026 12:13:17 -0400 X-MC-Unique: yb8WBD7NOKuYO7NAUugRFA-1 X-Mimecast-MFC-AGG-ID: yb8WBD7NOKuYO7NAUugRFA_1782317596 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-490cc1ae292so109055e9.1 for ; Wed, 24 Jun 2026 09:13:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782317596; x=1782922396; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Jd4PxTezgu22Dhpb7H7V7AiulDdRU6rhfSqzuxbdYWs=; b=n9Lf5IEiFsmTpblj3FFX07ncKzXEX1Mce/pvp5sm65gYwjG6JprDP74E+4Q+KSHNoS CZIjw52obBkc7shPGrpeE1K17m+S+na//eRtpiVF8i1I52+TihtNDJ/Yai92njOFc1gU z+QwPWzzq9QRBlSUvSdZV2eYDnQDoPlOtGAp3roPu20tkiPHSREA+j0/TRG4xGMDX6XX 0PiK6eGSopAq8rVFdUwrDS4BJwcSkAt7OpkQzD9rA88xXZYv9nkJhb8vYtukVJyK3efu aahxcWw8s1WUv88ekB/d67lMcu8jPOtg5HpzQD/ms4Oz6Thf99K68xN1fAp8yiSqDyfY 7isw== X-Forwarded-Encrypted: i=1; AFNElJ8jjkZJUsmZ8U6IMEhJJWMjMhA93saNsHo61RGXazV1ojMhYLmZ/vp5J+jCTHKYooZxeqw=@sourceware.org X-Gm-Message-State: AOJu0YyWmXWioCfbrfn2rGp97m7/Zw1/lRzd7AjBCcQCBla9s1WrLH3n bZSsBNZh3serU5E7/E0lslq0IXavx+YnNoqXppP6+UCJ9/H1N21H+dqOG0uTV2JuOHbORKqnNMJ s6Kp/gSBsEoDf97AeTWy+gWson3FmXpfvruAvAmtkyF7w8FE9diVn96qL1uqV X-Gm-Gg: AfdE7cnQxKbv0z9Ms9JMQemqhd5GniY0PFqQQOP8XLYlWfdon8DJotmgQ7h6VeyVb9f yvrqhw3/dTBQ6uc+SbJ57hvvIzRvG636vN6GkZl6W1/Nl5CmRf2FiybsgTj0SpnsRLxgF4NShd5 HJu6M4mpJfUHz8puy0SP3cx20tFgyYkWmmzFGAL8CBlqa8zcQuI3BgQjUJmGWZmyUKg6YUCWHl8 owmGrOL49K6yBeRn5+WVFLIPDBPZuNfgke0lbJrGEmMzoB7wbVnAL5KwLS86DxEPxCFA7FBk7I8 SiV2Ezi4P0x1ZUNp9Vlo8HNVtNZI+yRvw9pambom03KPb8BX0avQEDkpNRipcnVadVv+kYKZtLI /llUEj0RY9leJPpeOZEn13Tqj8hOiew== X-Received: by 2002:a05:600c:138e:b0:490:e19b:9632 with SMTP id 5b1f17b1804b1-492632b93e5mr15479005e9.17.1782317596478; Wed, 24 Jun 2026 09:13:16 -0700 (PDT) X-Received: by 2002:a05:600c:138e:b0:490:e19b:9632 with SMTP id 5b1f17b1804b1-492632b93e5mr15478635e9.17.1782317596004; Wed, 24 Jun 2026 09:13:16 -0700 (PDT) Received: from localhost (19.81.93.209.dyn.plus.net. [209.93.81.19]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49260d77e8asm40832265e9.1.2026.06.24.09.13.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 09:13:15 -0700 (PDT) To: Matthieu Longo , gdb@sourceware.org Subject: Re: Adding architecture-specific commands in GDB In-Reply-To: <077b9f00-ec84-440f-a84a-d804815aa77e@arm.com> References: <077b9f00-ec84-440f-a84a-d804815aa77e@arm.com> Date: Wed, 24 Jun 2026 17:13:14 +0100 Message-ID: <87ldc3or1h.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 2zbeLvFPJBw7gKDlMUOK522_x2Jq8rV7DrJJ2OCzo04_1782317596 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb Reply-To: Andrew Burgess Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Matthieu Longo via Gdb writes: > Hi all, > > Today, GDB seems to support architecture-specific commands for show/set [1]. However, it is not > clear to me whether any commands beyond the scope of show/set can/should be easily added. > > My usecase consists in adding AArch64-specific commands to dump some tables and permissions set up > by the Linux kernel. > > # Constraints: > 1. The tables are AArch64 specific and don't fit into an existing command. > 2. The permissions/capability views require to fetch information in different tables and procfs > files to be computed, so the computation of such permissions/capabilities is very tied to the > architecture specificities. > > Since I don't see how I could add those features to existing commands, I was thinking about adding > them under an "aarch64" namespace, and following the semantic of existing generic commands as much > as possible. > > # Examples > > ## Dumping the tables > > show aarch64 -tables [TABLE_NAME]* > > NB: those tables should only be set by the kernel, only read access is required. The content is tied > to the architecture. Maybe I'm wrong, in which case I'd love to see some counter examples, but the set/show command are usually for settings that are set by the user of GDB, and the show reads back the setting. Viewing kernel data would normally be an 'info' command. > > ## Dumping permissions > > aarch64 info [some other options and args] > > ## Dumping capabilities for a code or data > > aarch64 info caps [some other options and args] > > Please note that in the previous examples, is a subcommand of info, and > or caps are subcommands of . > Note: "info aarch64 " might make more sense than "aarch64 info > " given the existing show/set commands. > > Please let me know if adding such architecture-specific commands is possible today, or if it > requires changing the current commands framework. Yes adding these commands is totally possible today. Personally, I'd rather see it structured as: 'info aarch64 ....' as I think users are more likely to think 'info' to find out about the process, but I understand you might have a strong preference for the other order. > Those new commands would really be needed for debugging the new AArch64 feature and are not optional. > Is such an architecture-specific support undesirable ? No it's fine. You'd create the commands within an AArch64 only file, likely aarch64-tdep.c, or similar, within the per-file init function, look for 'INIT_GDB_FILE'. That way, the commands will only be registered for a build of GDB that includes AArch64 support. > Should such commands be moved to Python extensions even if they are essential ? I don't think there's anything wrong with writing commands as a Python extension. The commands can be included with GDB and always loaded. Of course, this does mean that a build of GDB without Python support will lack these commands, but these days it's pretty rare to find builds of GDB without Python support. Thanks, Andrew > > [1]: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Embedded-Processors.html#Embedded-Processors > > Regards, > Matthieu