From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 3GOjJ9IfEmnAIzMAWB0awg (envelope-from ) for ; Mon, 10 Nov 2025 12:24:34 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=stackframe.org header.i=@stackframe.org header.a=rsa-sha256 header.s=duo-1634547266507-560c42ae header.b=Vjgvgajo; dkim=pass (2048-bit key; unprotected) header.d=outbound.mailhop.org header.i=@outbound.mailhop.org header.a=rsa-sha256 header.s=dkim-high header.b=rYX/0L4Q; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=stackframe.org header.i=@stackframe.org header.a=rsa-sha256 header.s=dkim1 header.b=GVnZFhrx; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 963D61E0B8; Mon, 10 Nov 2025 12:24:34 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 C317F1E04C for ; Mon, 10 Nov 2025 12:24:33 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 758E93858409 for ; Mon, 10 Nov 2025 17:24:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 758E93858409 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, secure) header.d=stackframe.org header.i=@stackframe.org header.a=rsa-sha256 header.s=duo-1634547266507-560c42ae header.b=Vjgvgajo; dkim=pass (2048-bit key, unprotected) header.d=outbound.mailhop.org header.i=@outbound.mailhop.org header.a=rsa-sha256 header.s=dkim-high header.b=rYX/0L4Q; dkim=fail reason="signature verification failed" (2048-bit key, secure) header.d=stackframe.org header.i=@stackframe.org header.a=rsa-sha256 header.s=dkim1 header.b=GVnZFhrx Received: from chocolate.pear.relay.mailchannels.net (chocolate.pear.relay.mailchannels.net [23.83.216.35]) by sourceware.org (Postfix) with ESMTPS id 1AAA03858D2A for ; Mon, 10 Nov 2025 17:22:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1AAA03858D2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=stackframe.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=stackframe.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1AAA03858D2A Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.216.35 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1762795323; cv=pass; b=J+3NhYJy5E+QTbQVLGnoZiYyDu3J8S93PxqXdTYNHvwqAKbvXxIqT7L+i/TtfarPmzGgHnx3p1VUaiQ4yKrJ/PrY2X2aDwMXWJh9w4r6CU2sJ52VtA05yYdVccOONCdK2B+nGGynl8JcnMZj2CPphe5hLYMl6Rcrtr80Drz9TR8= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1762795323; c=relaxed/simple; bh=UI7LHggYxsPH/0iWW2/hvVBS2rNoxpy78ODwSspY5+I=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:From:To:Subject:Date: Message-ID:MIME-Version; b=h5EVh5vcgN/8m/7EbfREVQtCurQXuqBP9ecqfw8lGhIm4x5ruUEPihW5qNPAqtqA3gASZWVEOr+XLDfDdk7u2qZHhYTwfzeNXXNyGxwuMK0FC/esPlmBo5e6k8Z+tO6R51QijTwNkzj2/0qeXwlATFvEK40Icf7Du664gkbSL4U= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1AAA03858D2A X-Sender-Id: _forwarded-from|130.180.31.158 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 30D131805A6 for ; Mon, 10 Nov 2025 17:22:02 +0000 (UTC) Received: from outbound5a.eu.mailhop.org (100-125-88-56.trex-nlb.outbound.svc.cluster.local [100.125.88.56]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 93A4C180370 for ; Mon, 10 Nov 2025 17:22:01 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1762795321; a=rsa-sha256; cv=none; b=i/GhOLBmsxmRsJ037SrSbIBczNqGr4RD/RO6se1DbqOaAR/2ECQv0PUomFfe0YwCxmRW+G En2JpmDcVO/+7F6dFTeV5XY/QSIzpUXGCOCEVj4Pjl+duQIjClZL/XERnudYEF8KEMXz9k /iUi0KRY9c5H3ePemxr64GOWpMdbEmNysgpu9HTUrknQiveQs+/tjrLf5IxiGn4UnHb6ar C0Pd0f2DYQ4ecfvXNG/4jKk8tYIUrN3SgTqsSp3B01ox4SFFqGNlOLnmc30APYkbQjEzke 2WSVt6Eu9v5Ng2yrVSaTBapQm5Ph91IMghAIQ39SoQoo0uZ63d3FN2DTFszAMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1762795321; 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:dkim-signature; bh=TP/1tiBG/h7mMS2/8Prbd8achdlXop9CYinCNyWBDYI=; b=B3a3kH7Mz25Sui5Arek74azeyYDpSV+bt5GNK2KYa7bW6kt8ySOHAjFm2DMObYw5GPrHci Ot9gn4hxgJj2f/UeQmgFALNmUX8PGCH6eKteEo4ivyfrkP/KAL4kF0MZ2fVXDVFOvqgDrv YDlSChupM7VBQgWTCytr/o3nxZJ0WUTCXB0TEAYGvBpdj9bs9r6+U5LY3abYMxdjIHIO6x nSLV5Iaw3AIOK5Bcm0q0OlJ3SvRsVFXe1RaiK5HoSJ2/Z4w3XF+18txBz4XLT2hK7JQqYR 5tts6iMCNsUR+PY7fBEZwsjsGgIjV0LN6UDXvftmeqhio7IyrKC6lnCnUQ7QHw== ARC-Authentication-Results: i=1; rspamd-768b565cdb-7ttx7; auth=pass smtp.auth=duocircle smtp.mailfrom=svens@stackframe.org X-Sender-Id: _forwarded-from|130.180.31.158 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|130.180.31.158 X-MailChannels-Auth-Id: duocircle X-Cellar-Trade: 1b6b1feb7c4219f3_1762795322086_2258167886 X-MC-Loop-Signature: 1762795322086:1716424179 X-MC-Ingress-Time: 1762795322085 Received: from outbound5a.eu.mailhop.org (outbound5a.eu.mailhop.org [3.124.88.253]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.125.88.56 (trex/7.1.3); Mon, 10 Nov 2025 17:22:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stackframe.org; s=duo-1634547266507-560c42ae; h=content-type:mime-version:message-id:date:references:in-reply-to:subject:cc: to:from:cfbl-address:cfbl-feedback-id:from; bh=TP/1tiBG/h7mMS2/8Prbd8achdlXop9CYinCNyWBDYI=; b=VjgvgajoBRoGMVden0YdrQQe2P5WlnpWFL9UetBFYqVFciUzbJYlKCahtPj3Whx0ncQ+KEkGEnZxi B+IoCGUY9aMgJELwintRIf0+EVKUX4cY8h7irdznYG3SD4LnHW2Bi1FLPLSGYMoYVmBXJenqulUapn jRQ/xj8eErXnC3K8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:mime-version:message-id:date:references:in-reply-to:subject:cc: to:from:cfbl-address:cfbl-feedback-id:from; bh=TP/1tiBG/h7mMS2/8Prbd8achdlXop9CYinCNyWBDYI=; b=rYX/0L4Q25jdcGpzy4JNtZ8U2y4CV4Oh9ysymqfNjTgduss6u94KCm6lqKjum39o1izmor++cLDpU Je7mDf0iv16VvO5sNs5Y6irij9EfTdi6s6c0S8NW0hjjbW1eCb/OOSKzfftxvEfFufBef3jdG9JBL3 ZkfuZh1QTtk/ZNL1hxWxGxZ2P+F2haLjKIg22zlQEpIeQwqoW5O1zS1loax4gjtOM5Zud84k0czRpP 6fFLrG6iQFvpFrKMPzecfPQLZVc98H3yY1hixXOFsO34Q0o7o/flitObxaVQCtRAZhXygljXB86hzJ OFrmpvPhjDqV9BD0UXE3Pde04/YSg6Q== X-Originating-IP: 130.180.31.158 X-MHO-RoutePath: dG9ta2lzdG5lcm51 X-MHO-User: c073ca94-be59-11f0-b959-5f56af36decb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP CFBL-Feedback-ID: c073ca94-be59-11f0-b959-5f56af36decb:9 CFBL-Address: prvs=040923d279=abuse@outbound.mailhop.org; report=arf Received: from mail.duncanthrax.net (mail.duncanthrax.net [130.180.31.158]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id c073ca94-be59-11f0-b959-5f56af36decb; Mon, 10 Nov 2025 17:21:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=stackframe.org; s=dkim1; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TP/1tiBG/h7mMS2/8Prbd8achdlXop9CYinCNyWBDYI=; b=GVnZFhrxM4YI47mGUKD4bMERGQ 4bmYLddFmEV8o+Q0cyHLKb6vW9IYGvB2clF74ZdeC7E0tx1QPB3nRmTfYhzi9GApfFsp6gkgbrF2V Q1t290UQalPxpkzT7d2aj8mEsDTfcCZLMfyc7R/PprmFaZCxZK3c7krw/B4MNVTnfsjUaEavfwP6Q T96bb8GsXUo2xYqE3Afvf0GvlxArnNnloJaQQiSMUiktJ10ovyjBBxPwwLd7+3+nrvzCwJW91LqmN 2KKGHzsvCUvZlr4S4rfLC//nhwN+Ivw41+q9pzqBrmyqRWDMfgp3jYtAy4Jq08zWIGu3Y3dQi9lAL Tz06KZ3Q==; Received: from [134.3.93.166] (helo=debian.stackframe.org) by mail.duncanthrax.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97) (envelope-from ) id 1vIVaT-00000005mgq-2qNq; Mon, 10 Nov 2025 18:21:53 +0100 From: Sven Schnelle To: Simon Marchi Cc: gdb-patches@sourceware.org, Helge Deller , John David Anglin , binutils@sourceware.org Subject: Re: [PATCH v2] gdb/hppa: guess g packet size In-Reply-To: (Simon Marchi's message of "Mon, 10 Nov 2025 11:52:39 -0500") References: <20251104063038.62645-1-svens@stackframe.org> Date: Mon, 10 Nov 2025 18:21:42 +0100 Message-ID: <874ir1kdll.fsf@stackframe.org> MIME-Version: 1.0 Content-Type: text/plain 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 Simon Marchi writes: > On 11/4/25 1:30 AM, Sven Schnelle wrote: >> With qemu supporting 64 bit now, add some code to determine the >> register size of a hppa remote target. >> >> Signed-off-by: Sven Schnelle >> --- >> >> Changes in v2: >> >> - adjust coding style >> - use target_desc_up, make it static >> - use nullptr instead of NULL >> >> gdb/hppa-tdep.c | 51 +++++++++++++++++++++++++++++++++++++++++++------ >> 1 file changed, 45 insertions(+), 6 deletions(-) >> >> diff --git a/gdb/hppa-tdep.c b/gdb/hppa-tdep.c >> index 96cb797c023..bd250408951 100644 >> --- a/gdb/hppa-tdep.c >> +++ b/gdb/hppa-tdep.c >> @@ -2991,15 +3012,28 @@ hppa_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) >> = gdbarch_alloc (&info, gdbarch_tdep_up (new hppa_gdbarch_tdep)); >> hppa_gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); >> >> - /* Determine from the bfd_arch_info structure if we are dealing with >> - a 32 or 64 bits architecture. If the bfd_arch_info is not available, >> - then default to a 32bit machine. */ >> - if (info.bfd_arch_info != NULL) >> - tdep->bytes_per_address = >> - info.bfd_arch_info->bits_per_address / info.bfd_arch_info->bits_per_byte; >> + /* Determine from the target description if we are dealing with >> + a 32 or 64 bits architecture. If the target description is not >> + available, then check whether bfd_arch_info could be used. >> + Otherwise default to a 32bit machine. >> + */ >> + if (info.target_desc != nullptr) >> + { >> + if (tdesc_property (info.target_desc, PROPERTY_GP64) != nullptr) >> + tdep->bytes_per_address = 8; >> + else if (tdesc_property (info.target_desc, PROPERTY_GP32) != nullptr) >> + tdep->bytes_per_address = 4; > > What happens in the (not shown) "else" branch here? It seems like > bytes_per_address won't be set and we'll hit the internal error below. > Should we error out? I'm afraid I didn't get the question, because: if (info.target_desc != nullptr) { if (tdesc_property (info.target_desc, PROPERTY_GP64) != nullptr) tdep->bytes_per_address = 8; else if (tdesc_property (info.target_desc, PROPERTY_GP32) != nullptr) tdep->bytes_per_address = 4; } else if (info.bfd_arch_info != nullptr) { tdep->bytes_per_address = info.bfd_arch_info->bits_per_address / info.bfd_arch_info->bits_per_byte; } else tdep->bytes_per_address = 4; So tdep->bytes_per_address should be set. >> @@ -3122,6 +3156,11 @@ hppa_dump_tdep (struct gdbarch *gdbarch, struct ui_file *file) >> INIT_GDB_FILE (hppa_tdep) >> { >> gdbarch_register (bfd_arch_hppa, hppa_gdbarch_init, hppa_dump_tdep); >> + hppa_tdesc32 = allocate_target_description (); >> + set_tdesc_property (hppa_tdesc32.get(), PROPERTY_GP32, ""); >> + >> + hppa_tdesc64 = allocate_target_description (); >> + set_tdesc_property (hppa_tdesc64.get(), PROPERTY_GP64, ""); >> >> add_cmd ("unwind", class_maintenance, unwind_command, >> _("Print unwind table entry at given address."), > > I'm not super familiar with remote target descriptions, here's my > understanding of what is happening, please let me know if this is > correct. The target descriptions you create are never actually used are > target descriptions, but are just some "flags" to indicate whether the g > packet size guess resulted in 32 or 64. It seems a bit silly / strange > to use a target description this way, but perhaps there's no better way > with what we currently have. Are there other arches in GDB that work > this way, that I could reference as "prior art"? > > I guess I'm just slightly worried that something that uses this > gdbarch_info with a non-nullptr target_desc will see "oh, there a > target_desc, let me use it". Then the results will be bogus because > it's not an actual target description. But it's perhaps fine in > practice, and it's still a step forward. > > If the above is correct, can you add some comment to indicate that the > target descriptions are not actually used to describe target registers, > and what its real purpose is? I think I stolen the code from mips a year ago because register_remote_g_packet_guess() takes a target description. If it's a bit idea to do that, I need to find another way. But i don't know the gdb code well enough, so I can't say.