From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26447 invoked by alias); 7 Apr 2010 17:34:15 -0000 Received: (qmail 26415 invoked by uid 22791); 7 Apr 2010 17:34:08 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Apr 2010 17:34:03 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L0I00D00OQD8R00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Wed, 07 Apr 2010 20:33:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.92.42]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L0I00B4YOS98N70@a-mtaout22.012.net.il>; Wed, 07 Apr 2010 20:33:46 +0300 (IDT) Date: Wed, 07 Apr 2010 17:34:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] Fix for Go32-v2 native woes In-reply-to: <20100407144132.GA30700@caradoc.them.org> To: Daniel Jacobowitz Cc: hjl.tools@gmail.com, pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83tyrnw4jg.fsf@gnu.org> References: <002a01cad517$d36eab90$7a4c02b0$%muller@ics-cnrs.unistra.fr> <001801cad593$8e70daf0$ab5290d0$%muller@ics-cnrs.unistra.fr> <83iq84xyoa.fsf@gnu.org> <83y6h0vtj6.fsf@gnu.org> <20100407144132.GA30700@caradoc.them.org> 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: 2010-04/txt/msg00141.txt.bz2 > Date: Wed, 7 Apr 2010 10:41:37 -0400 > From: Daniel Jacobowitz > Cc: "H.J. Lu" , pierre.muller@ics-cnrs.unistra.fr, > gdb-patches@sourceware.org > > > Btw, what happens with the register-related features you added if > > libexpat is not linked in? Do these features silently disappear > > (good) or break the build (bad) or cause fatal internal errors at run > > time (worse)? > > They continue to work (even better). We parse the XML files used for > native debugging into C files, and the generated C files are stored in > the source tree. This was a design requirement before we could > require XML descriptions for any native platform. Thanks. So this means we currently assume SSE support regardless of the XML files, is that right?