From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21095 invoked by alias); 14 Jun 2008 00:16:21 -0000 Received: (qmail 21079 invoked by uid 22791); 14 Jun 2008 00:16:19 -0000 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Jun 2008 00:15:46 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m5E0FgIQ005666 for ; Sat, 14 Jun 2008 02:15:42 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402::142]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id m5E0Fgpc088553 for ; Sat, 14 Jun 2008 02:15:42 +0200 (CEST) Received: from d620muller ([130.79.244.152]) by mailserver.u-strasbg.fr (8.13.8/jtpda-5.5pre1) with ESMTP id m5E0Fca6041183 for ; Sat, 14 Jun 2008 02:15:42 +0200 (CEST) From: "Pierre Muller" To: Subject: [RFC/gdb/testsuite] Another way to avoid the windows native tty troubles Date: Sat, 14 Jun 2008 05:00:00 -0000 Message-ID: <000201c8cdb3$caa41490$5fec3db0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::153]); Sat, 14 Jun 2008 02:15:42 +0200 (CEST) X-Virus-Status: Clean 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-06/txt/msg00254.txt.bz2 Sometime ago, I proposed a patch that was trying to cope with the tty problem on windows cygwin and mingw targets. The patch was for an individual test, gdb.base/fileio.exp http://sourceware.org/ml/gdb-patches/2007-12/msg00045.html Several answers concerned the reasons of the tty problems, but I was mainly interested in getting more reliable testsuite results for windows targets. Lots of tests fail simply because the programs think that they are not on a terminal and thus use full buffering, which is incompatible with the testsuite logic. But, as Pedro said, individual files are not the right location to fix this. I finally came up with a different idea, that seems to work now quite well. The idea is simply to add an object that call setbuf(stdout,NULL) in a function that is added to the ctor section. The source gdb.arch/cygwin-ctor.c is simply: $ cat ../gdb.arch/cygwin-ctor.c #include void disableoutbuffer () { setbuf (stdout, 0); } asm (".section .ctor"); asm(" .long _disableoutbuffer"); <<< End of cygwin-ctor.c file >>> This file can be compile with gcc as cygwin-ctor.o or with gcc -mno-cygwin as mingw-ctor.o (allowing to use it for mingw tests, even if those still have lots of other problems). Adding this object at link time is done in gdb_compile proc in lib/gdb.exp (see below). This allows me to get about 80 failures less and more than 100 passes more for cygwin testsuite. The tty troubles are still visible in the three remaining failure in gdb.base/fileio.exp (instead of 38 failures usually) concerning istty tests for stdin stdout and stderr. The gdb_compile procedure change is rather simple, but it could probably be made more universal by converting this into a target info property that would be set in site.exp file for instance. setcurrtarget_info always_link 'mingw-ctor.o' In that case site.exp could also contain the code needed to compile this object from the source. I tought about putting the object generation inside the gdb/testsuite Makefile, but this would mean that people using 'runtest' directly inside the testsuite directory would get into troubles... I would like to know if such a testsuite change could be considered for inclusion in CVS tree, and in which direction I should go regarding these questions: 1) Should the patch stay cygwin/mingw specific or is there any interest in using the more universal target info approach that I tried to explain above? 2) How should I cope with the object generation? 3) There is one compilation failure that seems to be specific to my patch and is related to a compilation using the -nodefaultlibs option in gdb.base/prelink.so. This probably means that cygwin is not linked in. Note that the compilation also fails without my patch, but for some other reason (probably because some of the linked object do require cygwin). All comments most welcome, Pierre Muller Pascal language support maintainer for GDB $ cvs diff -up gdb.exp Index: gdb.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v retrieving revision 1.102 diff -u -p -r1.102 gdb.exp --- gdb.exp 4 May 2008 04:04:11 -0000 1.102 +++ gdb.exp 13 Jun 2008 23:49:55 -0000 @@ -1541,6 +1541,7 @@ proc gdb_compile {source dest type optio global gdb_wrapper_file; global gdb_wrapper_flags; global gdb_wrapper_initialized; + global objdir; set outdir [file dirname $dest] @@ -1626,7 +1627,18 @@ proc gdb_compile {source dest type optio } set options [lreplace $options $nowarnings $nowarnings $flag] } - + if { ($type == "executable") && + ([istarget "*-*-mingw*"] + || [istarget *-*-cygwin*] + || [istarget *-*-pe*])} { + verbose "Adding ctor to avoid buffer flushing problems" 2 + if [istarget "*-*-mingw*"] { + lappend options "additional_flags=${objdir}/mingw-ctor.o" + } else { + lappend options "additional_flags=${objdir}/cygwin-ctor.o" + } + } + set result [target_compile $source $dest $type $options]; # Prune uninteresting compiler (and linker) output.