From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id N2dkFqcY8mj07DsAWB0awg (envelope-from ) for ; Fri, 17 Oct 2025 06:21:27 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=mNF1xvmI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3B9AE1E04C; Fri, 17 Oct 2025 06:21:27 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 4F7B21E04C for ; Fri, 17 Oct 2025 06:21:26 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C28C33857BBA for ; Fri, 17 Oct 2025 10:21:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C28C33857BBA Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=mNF1xvmI Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id D6DC73858D1E for ; Fri, 17 Oct 2025 10:20:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D6DC73858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D6DC73858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::330 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760696452; cv=none; b=TPbRDIb6FwfgsOxLUgae0EgJzQl2sUVxhW/yPaE0RVdpE5ED6U6j4rELkUbzXLQ1UI2dYYEqD+lKJtc1BBFyuTNcDupBMZn35BbFM7ZEpolVCa1mDiKRQYQ/JRAvC3s+N1SU+iDFam+vX/jJVq/vG0cQsDWLB9TIDykOo4GljS8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760696452; c=relaxed/simple; bh=jr3LTL9EDuL3AmlQcP9+ahfUu4l5xqjrRfWw308x5XE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=AJLF7my4s26FDqgc/DY0/g8Uy+qaCMEd1Noz4Jds0IOXgNrlcC2Yh/c5HHS0zP4jTnotEmgz5bbixWBUOh1ykuwckNeogXfcgvfEKPLJQ4LFxsmTO350IMb0gUzoETJT7UOrQoLN/poNpdjDXLfgnl043puFv2n9el+GQVsq6Ag= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D6DC73858D1E Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4711810948aso8224325e9.2 for ; Fri, 17 Oct 2025 03:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760696450; x=1761301250; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=x9gHYrGgGFsRluN+fY0yfkjCchwxbpdjPDPvlj/5zMU=; b=mNF1xvmIisS8gGomSUzUDDVxeZ0BJgLr6RiNagw6GOiebPW9MOiCBwFl7X4IMn9Jjo 0FG/9ISXCw2pjhw/Uy7o+TS6/633tNEI1GpF4nmLWxXFfzRaXWTTc4EQym7VxwehIij2 fX9gGKx9ne4btV4sKPac6svI9cgEha7+1rJbitqWS84V4yaMqZLwcDDV+p/KeIaCg3th zyYaFHn9D59hz/a9mTgLNLI5H6cX3gfxZsFP0azy9YRz1OfNKMeA1UJnvvyPF8mz8CW+ QLsGgm5Pfyb3uzpsDDn1Z464VlClHMCgzHHLAEea5QELkuD9WvLB6dvfLt3X/a8t+AuU Mv4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760696450; x=1761301250; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x9gHYrGgGFsRluN+fY0yfkjCchwxbpdjPDPvlj/5zMU=; b=AaG55HoAl7nHqR9oKrT3loGQV4TYl97nu62CAl2KGWsLgWAD4QXyK04O3MonVlSjCk apgeIZf9mPOtulkl6Ylgnh4xcxNb8swDxwgrkw0lfl01eTNPO0d13z87gmO4Sl0VK6i/ GqMIB7qPvK7eIOTRpCUCC7ByS/XaYprG1vh8UHW4M+gKGFc3PNqxT3Q+O28j5dxuQyW8 eiIZMDth1+mowtX7DjxiGTl2RPMRlOS/LGLay1i99x1sPKJMKqdkc5plZcgAW/v8pjsi b0fVtGo+tWX8eQ9IdppP6f2l+w5rEi149zQ3yO0+RUjnF6uMspAMyJW/7h8p8G59CVe9 fIOQ== X-Gm-Message-State: AOJu0YyvXsx10CZoo++gIL1rWwXmQA2LRGvQ7OC5tUI72SpanJ9ArxFc RpuTRtnLPNNmj5m9Fsx1wPLJTJTHENritI/nl18+D98uN4hsB/zWCNZ9 X-Gm-Gg: ASbGncum2FcjatPDhEM5Lg/ldQxjv5nsQCOSKSTSgHMbR1ClmbSGVD7hRrWU2P1nRgw 4lnzhV+YRMKpFmq6JnQS3OS8uI4dHDTkQYvG2hXTztLyW4CWPxkO2nQiDL4Cl2gx0JYhD+ARdYC A8nwutyBZzsQaylouVFRINtKeHyQW2BzPIFoUZ+CKeHHn4o0FkZb4pQ1WQYQElzIDOVJwU8Pekd OeUQdpSdIpcMnLAb05Y6UYYATpjaLUxL83ZQNW1R4xxgNVjHeeA7GFVpjvsLdEIb2SeUJ/GH1R7 EIedCPwwKKerQ8Pl8wQYRkuSyklryEYkER9AXiirHmTo9gnl+AILZNYEOJHvPnpCAJws/uejrT7 dMkDEZLVk4mnAWFuffkCCZ5oVVrDq1N2EuqiGgk7UPYJ1r6k1CykBldXmhVLhLxGcW0Fktt65Qq lrJqCa9MaPNHpEnHlhb7P/YKI= X-Google-Smtp-Source: AGHT+IGXzMLSIAjT74O1Sp+GgrHRuZnkNQ9Akx5K+VPKQTO3nvZXvG72IZBFYfU75lXY4tSgspmarg== X-Received: by 2002:a05:600c:3f10:b0:46e:59f8:8546 with SMTP id 5b1f17b1804b1-471178afb7amr21993145e9.17.1760696450226; Fri, 17 Oct 2025 03:20:50 -0700 (PDT) Received: from [192.168.0.38] ([86.12.216.189]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4711441f776sm81856225e9.3.2025.10.17.03.20.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Oct 2025 03:20:49 -0700 (PDT) Message-ID: Date: Fri, 17 Oct 2025 11:20:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers To: Ezra Sitorus Cc: gdb-patches@sourceware.org, pedro@palves.net References: <20250925211804.21967-1-Ezra.Sitorus@arm.com> <20250925211804.21967-4-Ezra.Sitorus@arm.com> <148a9787-fe74-4ebb-99dd-8a50174510ce@gmail.com> Content-Language: en-US From: Luis In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 14/10/2025 01:56, Ezra Sitorus wrote: > On Sat, Oct 11, 2025 at 02:10:11PM +0100, Luis wrote: >> Hi Ezra, >> >> Given Pedro's input about the representation of fp8's, I'm not sure this is >> the right path. Enabling these types for the registers would also make the >> types visible to the rest of GDB. And users can operate on them via >> arithmetic operators etc. >> >> Being integers, the ending result wouldn�t be correct. >> >> It might be viable to explore the python extension option to print the types >> accordingly. We already make vector fields (neon or sve) available as 8, 16, >> 32, 64 and 128 integers. Converting from that would therefore be easy. >> > > Fair! I think a python pretty printer is a good idea. However, would a pretty > belong in the gdb project or the gcc project? The only examples in gdb are from > testcases. The gdb docs references gdb.libstdcxx.v6, but this exists in gcc. In > either scenario, I'm not too sure where the actual files would go to. > Right, these pretty printers usually go with whoever is producing/using such types. So libraries/compilers etc. With that said, we could also have a set of pretty-printers in gdb as well as reference implementation. >> Also, I'm not too keen on expanding even further these neon/sve union types. >> They are very hard to parse due to the multitude of representations. Ideally >> we�d put together some pseudo-registers to do the job. That would also help >> with remote debugging stub target description compatibility, as those >> wouldn�t need to expose these internal details of gdb. > > Your previous comment seems to suggest adding a pretty printer for the registers > too but this one seems to suggest adding pseudo-registers instead. For pseudo-regs, We should explore the python pretty-printers here. I don´t think we should add pseudo-registers in this case. But if we ever have a new representation, I think we should steer away from adding new union fields... > would the approach be something like putting the new float formats in aarch64-tdep.c, > and assigning the new pseudo regs' types to be the fp8 float formats? ... and then we´d have something like you describe above. Otherwise trying to print one of the vector registers produces a wall of text that is hard to parse. > > Thanks! > > Ezra