From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2303 invoked by alias); 22 Oct 2008 13:38:14 -0000 Received: (qmail 2293 invoked by uid 22791); 22 Oct 2008 13:38:13 -0000 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog012.obsmtp.com (HELO eu1sys200aog012.obsmtp.com) (207.126.144.126) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Oct 2008 13:37:26 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Wed, 22 Oct 2008 13:37:23 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6370CDAD6 for ; Wed, 22 Oct 2008 13:37:23 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 451004C282 for ; Wed, 22 Oct 2008 13:37:23 +0000 (GMT) Received: from crx595.cro.st.com (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.8.7a) with ESMTP id CQE85641 (AUTH "denis pilat"); Wed, 22 Oct 2008 15:38:29 +0200 (CEST) Message-ID: <48FF2C92.8020301@st.com> Date: Wed, 22 Oct 2008 13:38:00 -0000 From: Denis PILAT User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Denis PILAT , gdb-patches Subject: Re: Mingw gdb validation References: <48FC4417.2030807@st.com> <20081022132606.GA9276@caradoc.them.org> In-Reply-To: <20081022132606.GA9276@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-10/txt/msg00541.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Oct 20, 2008 at 10:40:55AM +0200, Denis PILAT wrote: > >> Is there any chance for such a patch to be accepted ? >> It allows the following test to be successful when using a MinGW gdb >> (means a gdb compiled under MSYS environment or using >> CFLAGS="-mno-cygwin" under cygwin). >> > > That depends why it's necessary... we have been testing mingw GDB > binaries for at least a year, and I've never seen this failure. > Are you using a Cygwin expect binary to drive the GDB? > No I'm using ActiveState version of expect. I didn't know it was possible to test non-cygwin GDBs in a cygwin environment. Each time I tried in the previous years, it fails. Is there any specific stuff do apart from running runtest ? > >> If yes I will write a correct changelog entry. >> The following $nl value is the only one that works both on linux and >> windows when running a validation. >> >> >> About gdb.cp/userdef.exp, I don't understand why only in part of the >> tests we have a \r\n expected as the answer ? >> gdb_test "print one % two" "\\\$\[0-9\]* = {x = 2, y = 3}" >> gdb_test "print one && two" "\\\$\[0-9\]* = 1\[\r\n\]" <===== Why >> expecting \r\n here and not above ? >> > > I don't know either, there it can probably be removed. It was > probably to ensure that there wasn't another character after the 1, > but gdb_test already does that. > Thanks, that's an explanation. Denis