From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id NUwhHdYkEmnGMDMAWB0awg (envelope-from ) for ; Mon, 10 Nov 2025 12:45:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1762796758; bh=g0ohNg8zMEuzyqY+PHcGnFOrNqW+yMdhI7TzCF5mB28=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=g69Y2g4DK7vIjqxaPI/He7nUwkLbER9KVRiGzi99byRLWW2UqOtCSUZK1n5+h5bby iVxqkwkKR2Px6tmUYapR9lEUJrdPwprN6fMk20nYW5n8fHdF7oe9VEFlBlIpD4WPSm +/TCCVNRV7sbVhdAcDFpLuCTcLP87LHfIP6ldSig= Received: by simark.ca (Postfix, from userid 112) id 627AC1E0B8; Mon, 10 Nov 2025 12:45:58 -0500 (EST) 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,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 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Imqs2nJA; dkim-atps=neutral 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 BE52A1E04C for ; Mon, 10 Nov 2025 12:45:57 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 574043858C52 for ; Mon, 10 Nov 2025 17:45:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 574043858C52 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Imqs2nJA Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id DF8103858C36; Mon, 10 Nov 2025 17:38:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DF8103858C36 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DF8103858C36 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762796332; cv=none; b=LFrynq72EcoiagfMTcDYcnqyAEcgni1CkxJZQFYPDl2+fKWVkPSc0xOt1q/pE/PgdF5zXqX+h53AIG8xYg3KNHKbNKgXLbUZwInagoatoi0bTiDdr2fYQHItIM3uoZv1ksliDknJFXUQRtDL9p94BMAglQPuogC9Y7KtnNqnQxk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762796332; c=relaxed/simple; bh=g0ohNg8zMEuzyqY+PHcGnFOrNqW+yMdhI7TzCF5mB28=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=fupcmIeCTzNhWG82gk7faPARlYh2Rx3M9pfg5h3vuqmFaJSnyhMZ8XWb1C851JKbDGqqbsJPdKRGi0dHoDS1rWLu98atmNeJZ4lFWVGAOVIfb2z08u8cc27ZoNRSAGvKoCZtn+jWBbqZdgCxAbYWefs2V7nrxLkjKJ7aITZDnUs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF8103858C36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1762796331; bh=g0ohNg8zMEuzyqY+PHcGnFOrNqW+yMdhI7TzCF5mB28=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Imqs2nJAPTAUIjH4bxuFSlmSsCmkfxt1kcLdz2IcKJbC7cLpUZ47z/2C97u0jKcE4 4BtIfM5dkVrkFeckx0NFQyI3QjaY0qwINtKny3G5G8kmMMtAcfbK/iIYaMVRqCv9Fo NVm8PUJlncH1jifDgy/iVU4L8ZnQ+uAgV4tNzJA8= Received: by simark.ca (Postfix) id 5CC4C1E04C; Mon, 10 Nov 2025 12:38:51 -0500 (EST) Message-ID: <4226a0b6-462e-46ee-afe4-46abaf292aa7@simark.ca> Date: Mon, 10 Nov 2025 12:38:50 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb/hppa: guess g packet size To: Sven Schnelle Cc: gdb-patches@sourceware.org, Helge Deller , John David Anglin , binutils@sourceware.org References: <20251104063038.62645-1-svens@stackframe.org> <874ir1kdll.fsf@stackframe.org> Content-Language: fr From: Simon Marchi In-Reply-To: <874ir1kdll.fsf@stackframe.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 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". >>> @@ -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. It is a bit odd but I don't see a better way. Well the better ways would be: 1. Write some target descriptions (store them in gdb/features). Select the right one using that "remote g packet guess" mechanism. That would replace the manual implementations of gdbarch functions like gdbarch_register_name and gdbarch_register_type. 2. Have qemu return a target description for the hppa architecture. To be clear, I don't expect you to do this (well, you can if you want to), it would be another project. Simon