From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15004 invoked by alias); 24 Mar 2018 02:06:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14700 invoked by uid 89); 24 Mar 2018 02:06:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Generation, Upon, sk:native-, sk:native X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 24 Mar 2018 02:06:50 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1E1E01E580; Fri, 23 Mar 2018 22:06:47 -0400 (EDT) Subject: Re: [PATCH v4 00/10] Remove gdbserver dependency on xml files To: alan.hayward@arm.com, gdb-patches@sourceware.org Cc: nd@arm.com References: <20180322084429.26250-1-alan.hayward@arm.com> From: Simon Marchi Message-ID: <7e3e1f1a-7dfc-3bd8-3436-046df6a471b8@simark.ca> Date: Sat, 24 Mar 2018 02:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180322084429.26250-1-alan.hayward@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-03/txt/msg00471.txt.bz2 On 2018-03-22 04:44 AM, alan.hayward@arm.com wrote: > From: Alan Hayward > > V4 addresses Philipps review comments. I'm fairly confident the issues he > found on s390 I reproduced on arm32, and have now fixed up - the code now > ensures xml is not generated for targets using older style descriptions. > > Using git sendmail for the first time, which should sort out the formatting > issues I've had previously. However, just to the safe I've also pushed to > my patches to the remote branch users/ahayward/xml4. > > This set adds two new patches to handle when to generate xml (fixing s390 > issues) and the reg_defs vector change. > > Summary: > > For those targets that use new style target descriptions, this set of patches > removes the dependency on xml files. Namely: > * Removes inclusion of xml files within gdbserver. > * Removes the requirement for the .c files in features/ to be generated from > cached xml files. > This is made possible by changing xml descriptions generated by gdbserver, so > that instead of including xml file names, gdbserver now generate a complete > xml description. > > The second point will be required for aarch64 SVE support, where the register > size are variable. Creating SVE xml files for every possible vector length > would not be feasible. Instead the plan for aarch64 SVE is to hand write the > features/ .c code that would normally be generated from xml. > > Targets which use the older style target descriptions have not been changed. > > > XML Generation: > > In existing code, gdbserver uses C code auto generated from xml files to > create target descriptions. When sending an xml description to GDB, the > function tdesc_get_features_xml () creates an xml containing the name of the > original xml file(s). For example: > > > > i386 > GNU/Linux > > > > > > > Upon receipt, GDB then makes requests to gdbserver for the contents of the > xml files. Gdbserver keeps full copies all the xml files inside the binary. > > This patch series adds common code that allows gdbserver (and gdb) to turn > a C target description structure into xml. > Now when asked fort an xml description to gdb, gdbserver turns the entire > target description structure back into xml, without using any cached files. > Producing, for example: > > > > i386 > GNU/Linux > > > > > > > ...etc... > > > Patch Contents: > > Patches 3-5 commonise the various target descriptor functionality, allowing > gdbserver to parse target descriptions in the same way as gdb. This series > does not commonise target_desc, but this is hopefully a long term goal. > > The eighth patch adds the xml printer, which iterates through the parsing > generated in the previous patches. > > The other patches are clean up patches. > > > > Patches have been tested on a make check on x86 targets=all build with > target boards unix and native-gdbserver. Also built and tested aarch64 and > Arm32 (which uses old style descriptions) > In addition, patch six adds new test cases to unit test. Hi Alan, I went through the whole series, so I am a bit more familiar with the problem now. I often see the terms "old" and "new" style target descriptions, but I am not really familiar with the differences. Reading this https://sourceware.org/gdb/wiki/TargetDescription this is what I understand: - old: An entire target description is pre-generated (as C code) for each possible configuration, possibly leading to a combinatorial explosion if there are many optional features. - new: Each feature is independently generated (as C code) and a hand-written function manually assembles the final target description at runtime, adding the necessary features based on the CPU features. Is that right, and is there anything more to it? Also, more long term-ish question, I never really quite understood the need for the regformats/*.dat step. Couldn't we directly go from XML to the generated C files when building gdb/gdbserver? Simon