From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 17OcCBDbB2c8owgAWB0awg (envelope-from ) for ; Thu, 10 Oct 2024 09:48:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1728568080; bh=mfh2cPYkKmFJzyCnbfnLtWn2mTCJSjx81Mk7iAYFRxI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=NS/tsLc4V0Lj2RVuW9I7MAjbU0ymNK6vmg/c8AR61rib+AwUFSZdhnvDM7S8iDVIR GtO1GU9grzaZfp7S1uaYyDXVqyfYb0XE37IJZ3X2NNfB4+D1/IYjrTYfRyj+ghPeCA kZlVVOeEutiMhqflWH4sLhN0/JK0CkuJ1SSO58Fs= Received: by simark.ca (Postfix, from userid 112) id F2B8B1E356; Thu, 10 Oct 2024 09:47:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=unavailable autolearn_force=no version=4.0.0 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=Z7N6F5v0; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=V+9qbLnA; 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 3F25D1E354 for ; Thu, 10 Oct 2024 09:47:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AA8FA3857346 for ; Thu, 10 Oct 2024 13:47:58 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 1F33B3857B9E for ; Thu, 10 Oct 2024 13:47:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F33B3857B9E 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 1F33B3857B9E 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=1728568059; cv=none; b=GvhZLdiIBYmQB2B49UcdjfKRp1kHzcxw54L1duQxUnKWyrQR3/ieopxfviS0tzhBVCzJMFTIhEqdCfk1MvfasX+dwsOhGKUllrBHpaJCA1u3QnnTE9b5nNufqtm0ONGYprXiClwveDuzTkKnBcKyTx6rTAvjVDsNOVzpiPqt9DM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728568059; c=relaxed/simple; bh=mfh2cPYkKmFJzyCnbfnLtWn2mTCJSjx81Mk7iAYFRxI=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=rDBx8PuNoAFrWgi6QlkFyO0WSMjZ29+iXOcSMfByTUhACvJORHUFwOAqZQ9uxUMF9ex7iMUDhscPmzDdNey0OeVOJOzDSzvpB0jNvZimA5hZWdhh5oYxeR0DZrlCLARtVUHsGaUMmrmuW3nXve3uyyXKsODJlF+pPhyB+Uudhm0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1728568056; bh=mfh2cPYkKmFJzyCnbfnLtWn2mTCJSjx81Mk7iAYFRxI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Z7N6F5v0Hwb1u1PLx8ke9VuE86YSeuDg6FNSturY6EQ1dT0sZaLUO25ddWWyX3+ac hG1MTjTw5LNN1u/2RKVwhcgCRknVVLxKZjOtMB/kJmR+kyUEV8s8Y/YbHNTFISjPkM E9QPNnasoMuqFHW7ShC7fNBKM1hnZVzojEBNQBh4= Received: by simark.ca (Postfix, from userid 112) id 589B01E356; Thu, 10 Oct 2024 09:47:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1728568053; bh=mfh2cPYkKmFJzyCnbfnLtWn2mTCJSjx81Mk7iAYFRxI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=V+9qbLnA/55jIofd7BQohUO3dMjCdZuoF0A4WtCaWsDKDmp+h9yz7ktfDo/mBakmv rl2y3/RoS0xsiFPoCRsdjCvAbDTSic/MTWdm+6XAwaFff7MZQww1nfWBTmpnnNCB8k bUncN8LbAxIVU4NoKLc9tXQ7TQl1F/lXI8P46syc= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 245E41E354; Thu, 10 Oct 2024 09:47:33 -0400 (EDT) Message-ID: <3e2be9d9-8322-4a29-9b6b-af48262fd9e0@simark.ca> Date: Thu, 10 Oct 2024 09:47:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] gdb: split osabi support between gdb/ and gdbsupport/ directories To: Andrew Burgess , gdb-patches@sourceware.org Cc: Luis Machado References: <63b58681b3abc4ef52c2b17c10bcb26a1a5033ea.1728407374.git.aburgess@redhat.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <63b58681b3abc4ef52c2b17c10bcb26a1a5033ea.1728407374.git.aburgess@redhat.com> 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 2024-10-08 13:11, Andrew Burgess wrote: > In future commits I want to call set_tdesc_osabi from gdbserver/ > code. Currently the only version of set_tdesc_osabi available to > gdbserver takes a string representing the osabi. > > The problem with this is that, having lots of calls to set_tdesc_osabi > which all take a string is an invite for a typo to slip in. This typo > could potentially go unnoticed until someone tries to debug the wrong > combination of GDB and gdbserver, at which point GDB will fail to find > the correct gdbarch because it doesn't understand the osabi string. > > It would be better if the set_tdesc_osabi calls in gdbserver could > take an 'enum gdb_osabi' value and then convert this to the "correct" > string internally. In this was we are guaranteed to always have a was -> way > valid, known, osabi string. > > This commit splits the osabi related code, which currently lives > entirely on the GDB wide, between gdb/ and gdbsupport/. I've moved wide -> side > the enum definition along with the array of osabi names into > gdbsupport/. Then all the functions that access the names list, and > which convert between names and enum values are also moved. > > I've taken the opportunity of this move to add a '.def' file which > contains all the enum names along with the name strings. This '.def' > file is then used to create 'enum gdb_osabi' as well as the array of > osabi name strings. By using a '.def' file we know that the enum > order will always match the name string array. > > This commit is just a refactor, there are no user visible changes > after this commit. This commit doesn't change how gdbserver sets the > target description osabi string, that will come in the next commit. > --- > gdb/osabi.c | 91 ---------------------------------- > gdb/osabi.h | 41 +--------------- > gdbsupport/Makefile.am | 1 + > gdbsupport/Makefile.in | 15 +++--- > gdbsupport/osabi-common.cc | 98 +++++++++++++++++++++++++++++++++++++ > gdbsupport/osabi-common.def | 57 +++++++++++++++++++++ > gdbsupport/osabi-common.h | 54 ++++++++++++++++++++ Naming nit: do we really need / want "common" in the gdbsupport file names? I think that the file being in gdbsupport already says it's available to both gdb and gdbserver, so naming "common" seems redundant (I know we have a bunch of files called "common" already). > +const char * > +gdbarch_osabi_name (enum gdb_osabi osabi) > +{ > + if (osabi >= GDB_OSABI_UNKNOWN && osabi < GDB_OSABI_INVALID) > + return gdb_osabi_names[osabi].pretty; > + > + return gdb_osabi_names[GDB_OSABI_INVALID].pretty; > +} > + > +/* See gdbsupport/osabi-commomn.h. */ commomn -> common Simon