From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1LEwLajpImc9KSAAWB0awg (envelope-from ) for ; Wed, 30 Oct 2024 22:21:28 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=b2TYCL1E; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A616F1E5A1; Wed, 30 Oct 2024 22:21:28 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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=ham autolearn_force=no version=4.0.0 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 284901E37A for ; Wed, 30 Oct 2024 22:21:28 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B83893857835 for ; Thu, 31 Oct 2024 02:21:27 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id E34CF3858D21 for ; Thu, 31 Oct 2024 02:21:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E34CF3858D21 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E34CF3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730341267; cv=none; b=IXAw924KpEUFO/Dh/+JZUn8Oqu/eFZNHKuzIZclNFWxKNtbgLtvFxHtdnInSoeQyzhcuIk+wyam2muUErfW8iNxh4nbf1tp4UfzMDh9kHSYg/fY7vIWYd4lePaHdYgKv8qujylZMj9dOm+vl5A7P71NYSdjeOYbxEPhJx7vdmAY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730341267; c=relaxed/simple; bh=G0STEFAXx5UbryoLy82CWvjrNCLEEFyrP8sp5C4SM6A=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ikGN3njo1udjVSdga6C41yriAkqccOEXzMKLHqWsxcW1r3hwv3nraAcCHAwqXSXGUO0hOdqUdDq10sp503Dc7o1BOZKeKO94ES5BvYkXvYt5QgT7YuzuuRto205FKk7CfFk3EC9DThGBf4YX6V14VlAz6B4t2AbJAmII8PloW8Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730341264; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FvxlLFrhVR6FQQbxjjc/zixvCvk0WVOaq5cEpzQTekA=; b=b2TYCL1E8J4j5W3QGbfu580ggK0dfd1NzQXk6T7DyZ+WmKh37tIGwgGyxUZ/Y/yeNNdX6E ACzYLEvSQGCAnoO6l6Yjp8lykJj8gm257pwEDLE9R5Z/m1WY0yffrCOn1cwheLR15gTmk0 uSiezEsk4qm/Pn75qM5ToVSxFxrxFFQ= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-2f5gvt8MNIChBM6d7AEMmg-1; Wed, 30 Oct 2024 22:21:02 -0400 X-MC-Unique: 2f5gvt8MNIChBM6d7AEMmg-1 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B197119560A7 for ; Thu, 31 Oct 2024 02:21:01 +0000 (UTC) Received: from f40-zbm-amd (unknown [10.22.64.38]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D200F1956052; Thu, 31 Oct 2024 02:21:00 +0000 (UTC) Date: Wed, 30 Oct 2024 19:20:57 -0700 From: Kevin Buettner To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv5 2/3] gdb/regformats: add osabi information to generated .dat files Message-ID: <20241030192057.65a55191@f40-zbm-amd> In-Reply-To: References: Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII 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 Sun, 27 Oct 2024 20:07:41 +0000 Andrew Burgess wrote: > Some gdbserver targets generate their target description based on the > gdb/regformats/*.dat files. These .dat files are generated from a > matching xml file in gdb/features/. > > Lets consider a concrete example: > > Take gdb/features/or1k-linux.xml, this file is processed by > gdb/features/Makefile to create gdb/regformats/or1k-linux.dat. > > When gdbserver is built for the or1k target the file > or1k-linux-generated.cc is generated using the > gdb/regformats/regdat.sh script. This .cc file is then compiled and > linked into gdbserver. > > The or1k-linux-generated.cc file contains the function > init_registers_or1k_linux which is called from within gdbserver, this > function creates a target_desc object and sets its xmltarget field to > a fixed string. This fixed string is the xml filename that was > originally used to generate the xml file, in this case or1k-linux.xml. > > Additionally, as part of the gdbserver build the file or1k-linux.xml > is converted to a string and placed in the file > xml-builtin-generated.cc which is then built into gdbserver. > > Now when GDB asks gdbserver for the target description, gdbserver > returns the fixed xmltarget string, which is the name of an xml file. > GDB will then ask gdbserver for that file and gdbserver will return > the contents of that file thanks to the xml-builtin-generated.cc > file's contents. > > This is all rather complicated, but it does work. So what's the > problem that I'm fixing? > > Well or1k-linux.xml does contain the osabi information, so this will > be returned from gdbserver to GDB. That's good. > > However, the target_desc object created in init_registers_or1k_linux > will not have its osabi set correctly. > > Now this doesn't really matter too much except > init_registers_or1k_linux includes a call to init_target_desc. > > In the next commit I want to extend init_target_desc to require an > osabi to be passed in. The motivation for this will be explained in > the next commit, but if we accept for a moment that this is something > that should be done, then the question is what osabi should we use in > init_registers_or1k_linux? > > Ideally we'd use the osabi which is set in or1k-linux.xml. If we do > that then everything will remain consistent, which is a good thing. > > And so, to get the osabi from or1k-linux.xml into > init_registers_or1k_linux, we first need to get the osabi information > into or1k-linux.dat file, and this is what this commit does. > > I've added a new xsl script print-osabi.xsl and updated > gdb/features/Makefile to make use of this script. Then I regenerated > all of the .dat files. Now every .dat file contains either: > > osabi:GNU/Linux > osabi:unknown > > The first is for xml files containing GNU/Linux and the > second is for xml files that don't contain an osabi element. > > This commit doesn't attempt to make use of the osabi information in > the .dat files, that will come in the next commit. There should be no > user visible changes after this commit. Thanks for the detail explanation! Based on your problem description, etc, these changes make sense to me. Also, as there should be no user visible changes, I think this is good to go in. Approved-by: Kevin Buettner