From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59845 invoked by alias); 14 Apr 2016 13:28:32 -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 59827 invoked by uid 89); 14 Apr 2016 13:28:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=compose, Going, Together, feeding X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 14 Apr 2016 13:28:28 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 68B9D78234; Thu, 14 Apr 2016 13:28:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3EDSOwM031687; Thu, 14 Apr 2016 09:28:25 -0400 Subject: Build xml target descriptions at run time To: Walfred Tedeschi , Yao Qi References: <1457025942-23711-1-git-send-email-walfred.tedeschi@intel.com> <864mb4mqkm.fsf@gmail.com> <570F8019.3060101@redhat.com> <570F8B36.1070301@intel.com> Cc: Joel Brobecker , gdb-patches From: Pedro Alves Message-ID: <570F9AF8.6020200@redhat.com> Date: Thu, 14 Apr 2016 13:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <570F8B36.1070301@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00330.txt.bz2 On 04/14/2016 01:21 PM, Walfred Tedeschi wrote: > Firstly we also agree! :) > We have to agree upon a strategy and a design for that. > > I would propose that we go in the way it is by now for the patches that > are under review for me and Michael. Those patches impact technology > that is already public. > > Together with that we discuss the design on how to stich the target > descriptions together. > > Would you agree with that? I would. > > In terms of the design: > During this time we also proved that it would be possible to have a > single target description and selecting the features to be added > according to the feature bits during run time. > > The elegant option is of course the composition of the target > description under run time. But there is also the consideration of how > complex it would be. > > Have you already had some thoughts about that? Please share your thoughts as well... > Can you point us to some discussion about the topic? I'm recalling this being brought up at some Cauldron, and maybe (ISTR) Luis bringing that up on the gdb list somewhere. ISTR recall this coming up for MIPS as well. But I don't have pointers handy. I don't have a quick answer. Below's a couple minutes worth of thought, all I could spare right now. Always going through a xml built at run time might be the simplest. However, even that poses challenges. The xml-building part itself wouldn't be anything complicated. Just something along the lines of: x86_linux_read_description () { strcat (output, target_xml_header); if (feature_foo_supported) strcat (output, ""); if (feature_bar_supported) strcat (output, ""); strcat (output, target_xml_footer); return output; } However, gdb needs its own set of built-in target descriptions as well, for core file debugging, etc., and always going through the xml indirection would mean that libexpat becomes a hard requirement for native and core debugging as well, and, it'd require installing the xml files in the data-directory, along side gdb. It's convenient NOT to have to install the xml files today, but maybe that's not a deal breaker. Also, then there's the gdbserver side. gdbserver also makes use of the target descriptions for more than feeding a xml version back to gdb, and of course gdbserver doesn't parse the xml files at all. They're instead converted at build time to whatever gdbserver needs. So whatever design we come up with needs to address this as well. Going the always-xml direction means that now gdbserver needs to link with expat and parse the xml files. Or maybe we could come up with a design that avoids having gdbserver parse xml, by still converting the feature xml files to C at build time (like, generate a set of struct target_desc_feature objects (which don't exist today), which would correspond to each feature that could be xinclude'd), and then at run time compose a struct target_desc from those struct target_desc_feature object, as well as a xml file to send back to gdb. Thanks, Pedro Alves