From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SanYEhdHEmnfmzMAWB0awg (envelope-from ) for ; Mon, 10 Nov 2025 15:12:07 -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=LMJvOglc; 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=DYxPUn5T; 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=KpE118tm; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 48E691E0B8; Mon, 10 Nov 2025 15:12:07 -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 222A51E04C for ; Mon, 10 Nov 2025 15:12:06 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 328663858C74 for ; Mon, 10 Nov 2025 20:12:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 328663858C74 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=LMJvOglc; 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=DYxPUn5T; 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=KpE118tm Received: from outbound5h.eu.mailhop.org (outbound5h.eu.mailhop.org [18.156.94.234]) by sourceware.org (Postfix) with ESMTPS id 48A033858D20 for ; Mon, 10 Nov 2025 20:10:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 48A033858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=stackframe.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=stackframe.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 48A033858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=18.156.94.234 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762805433; cv=none; b=W+hvV9h2c5s512AJtyDIz5Lwg3CF9TPo/iOCU9PYNAFI1AJgpXrM9cQdjCIzv0Fk4OsLS5TD89i377A7GVlNTgsCh73KIhi7EcDeeErXVTXTSbmvqRiB8+RqygrBpXxiv8UmzZ2qWagFZDdEhS/DoUywu2c46qmmFcdIea9mrus= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762805433; c=relaxed/simple; bh=2YG36mDVlcmkh7xf3UgQ/aWN5x3Ok1RAwqpGPe1lZlU=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:From:To:Subject:Date: Message-ID:MIME-Version; b=aLJ4RgqDwYVB6MhrTNolUGBgmoPFcXCKDJ6h1gy332AVv1CxaeTt6ujCzDX4ViVhy9wDFeQzR/Y3uylO9fvB4Ndr5cbtysC/GO6Ch8fTQ3WF7KM+2sHCEcgjSXuusoke5n87/OOpBthFJHm6+P3rssOB/OGKeHn8eLZ55LmGVCw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 48A033858D20 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=+ICmSwm91vBBwinyDaL7QAqxX8mGOjTX2rwU9KB9IBo=; b=LMJvOglcRs7rNTNrQnlzPfgfYQihlTYs2BKSht2N5QDTWGBOnbS1gMfS99Ll/xMnx9gzUfZggFMzD LzM6LdcRZN3TW3BN8kNaJdnGSQB06U6kUGqohSYu60eHFtMO1/9CoYUHmAG7DeCbsxvCpywMJb4pZg Qs/FFAaq1yD0RYZg= 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=+ICmSwm91vBBwinyDaL7QAqxX8mGOjTX2rwU9KB9IBo=; b=DYxPUn5TxmyLcoltgvHjMO4DsF/h0idh55friIVdQ1dJm6XmH7RS3WxZn5qNIbrATiu3+zvWr2gGP 0/imYElGSEovvbpyrB9sozSn+3SV29YfvY7rj2YA1vyST1CT9vFhhxdSdylIpEXUBblqFRyaj8o3vd 9OhrKbUUhD1nJlXb2g2UbkMwMeiyn+LBolgae5uxuR/byv37GWaxBsajlBSZLMKpubTyE0uXTLGZvK K/mF4eHA7WhwJCIOPkT6Xd0JpFgPoXlkVVWUWqdN3PAP0zzA0YWcbuZIa64QfPxpldoO3Nkee/7j+d rqox/sSknv2zSaBVioWUHLMrOcd8F+Q== X-Originating-IP: 130.180.31.158 X-MHO-RoutePath: dG9ta2lzdG5lcm51 X-MHO-User: 4cf2ee72-be71-11f0-a007-310e225498a9 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: 4cf2ee72-be71-11f0-a007-310e225498a9:9 CFBL-Address: prvs=040923d279=abuse@outbound.mailhop.org; report=arf Received: from mail.duncanthrax.net (mail.duncanthrax.net [130.180.31.158]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 4cf2ee72-be71-11f0-a007-310e225498a9; Mon, 10 Nov 2025 20:10:28 +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=+ICmSwm91vBBwinyDaL7QAqxX8mGOjTX2rwU9KB9IBo=; b=KpE118tm1tNMpsl07cQEpAbULp cSJDk8nKTIcWwVXZR2aBH+lBfgpqXZzwxhtdejga+Ndxh+cYEyZzGGMapC/CVqn9W0Lbvc3v1A1jL jaXnqwthnIcpnYZeWfIHWxYp2KaqHCsDMzGpL8ObocL8DNWOxcQWPuKmZeSaSTy0+haJk3lRKYWsd RaP53T8HehMPajRHLlHj1GOWGyH5d7C/kNQ3KJURjE0aWEQ9FYbUQePrOOHY8mSccyIwDz+QXHQWo QRmoPDm4uUUy4BJKBqa2PnzOAOCWXK1AJH9V6hRJTQ3JocA9VaDCsJptlZ4D7KQ3X14nCuWeHk9Z1 uY5vr8yA==; 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 1vIYDb-00000005oZG-3LyH; Mon, 10 Nov 2025 21:10:27 +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: <4226a0b6-462e-46ee-afe4-46abaf292aa7@simark.ca> (Simon Marchi's message of "Mon, 10 Nov 2025 12:38:50 -0500") References: <20251104063038.62645-1-svens@stackframe.org> <874ir1kdll.fsf@stackframe.org> <4226a0b6-462e-46ee-afe4-46abaf292aa7@simark.ca> Date: Mon, 10 Nov 2025 21:10:26 +0100 Message-ID: <87wm3xir7x.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/10/25 12:21 PM, Sven Schnelle wrote: >> 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. > > I think we should do something where I wrote "What then?" below: > > 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 > // What then? > } > 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; > > Could we reach that place if e.g. qemu started to return a target > description for the hppa architecture? I suppose we can error out > saying something like "that target returned a target description but > this GDB doesn't support it for the HP-PA architecture". Ah, got it. Maybe we should default to 32 bit (as userspace is very likely to be 32 bit, only the kernel might be 64 bit right now), and print a warning in that case?