From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4061 invoked by alias); 5 Oct 2007 16:51:58 -0000 Received: (qmail 4053 invoked by uid 22791); 5 Oct 2007 16:51:57 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Oct 2007 16:51:55 +0000 Received: (qmail 8405 invoked from network); 5 Oct 2007 16:51:53 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Oct 2007 16:51:53 -0000 To: gdb-patches@sourceware.org Subject: Re: [rfc] Pre-parse XML target descriptions References: <20071005153350.GA23583@caradoc.them.org> From: Jim Blandy Date: Fri, 05 Oct 2007 16:51:00 -0000 In-Reply-To: <20071005153350.GA23583@caradoc.them.org> (Daniel Jacobowitz's message of "Fri, 5 Oct 2007 11:33:50 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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 X-SW-Source: 2007-10/txt/msg00056.txt.bz2 Daniel Jacobowitz writes: > So far, I've used the target description mechanism I implemented for > three purposes: > > - Remote targets, where the description is an XML file provided > either by the target or by a "set tdesc filename" command. > > - Built-in descriptions, which are constructed manually in C code. > For example the registers-are-64-bit MIPS property which we infer > from the size of a remote 'g' packet. > > - New native register sets, where the description is an XML file > converted to a C string and compiled into GDB. > > That last one is a bit unsatisfactory. It means that if we choose to > use an XML file to describe a target, then users of that target are > required to link with expat and will get slightly mysterious warnings > about disabled XML support if they don't. I'm trying to make the > use of data instead of code for these descriptions as attractive as > possible and this makes it unattractive. And I have a patch coming > up which changes an existing target rather than adding a new one. > > There's one obvious solution: require expat. But that's not > practical, it seems. So here's an alternative solution: convert the > XML files to equivalent C fragments and include them in the source > tree. It's fairly straightforward to do, and more efficient at > startup. You need an XML-supporting GDB for an appropriate target > that runs on your build machine to generate the C files, so it's not > practical to generate them automatically during build. Is this impractical because one must build GDB twice, or because one can't assume expat is present? If it's only the latter, then 'maint print c-tdesc' could be compiled in one of two ways, depending on whether expat is present: - When expat is present, it generates output as normal. - When expat is not present, it merely compares a wide checksum of the input file with a checksum stored in the output file of the input it was generated from, reports success if they match, and prints an error message saying "You need to rebuild GDB with expat, because you've modified your XML file" if they don't.