From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2262 invoked by alias); 23 Sep 2004 06:30:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2245 invoked from network); 23 Sep 2004 06:30:05 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sourceware.org with SMTP; 23 Sep 2004 06:30:05 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CAN7D-0003l0-00; Thu, 23 Sep 2004 02:30:03 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 980834B102; Thu, 23 Sep 2004 02:30:11 -0400 (EDT) Date: Thu, 23 Sep 2004 06:30:00 -0000 From: Michael Chastain To: me@cgf.cx, gdb-patches@sources.redhat.com Subject: Re: [RFC] Suggested ways to remove the need for xm-go32.h Message-ID: <41526D73.nailWK21NVX4@mindspring.com> References: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> <20040923050534.GA11936@trixie.casa.cgf.cx> In-Reply-To: <20040923050534.GA11936@trixie.casa.cgf.cx> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00365.txt.bz2 Christopher Faylor wrote: > MichaelC has indicated which systems support "rb". Is there any way to > somehow figure out if this is supported for the whole list of supported > targets? That brings up a tough philosophical issue. Well, okay, part of it is tough because it implies more work for me. There isn't a list of supported hosts or supported targets. The software itself has "list of hosts and targets that somebody, at some time in the past, contributed at least some work towards." The gdb-testers@ group records "somebody tested something and reported results in some way". That's where the "more work for me" comes in: devising some standard meta-information for a test run (like a little XML file, that's what I use in my test bed), and then augmenting the test suite to generate gdb-test-run.xml on every run, and then having people mail that in, and then begging more people to report their results, and then writing "Terf II" to keep track of it all. The release criteria for gdb is "break main ; run works on unspecified platforms". > Or can we try going without the wrapper function and move > to a wrapper function when someone complains? For the second question, from a support point of view, I want something that (a) works on a lot of systems and (b) when it doesn't work on some system, it's an obvious 1-line patch to work around the problem. So I don't like "no wrapper function but then change the code when someone shows up with a weird system". To avoid the wrapper function, perhaps probe for the modes at run time: static const char * read_mode = NULL; void set_read_mode () { FILE * fp = NULL; if (read_mode == NULL) { if ((fp = fopen ("/dev/null", "rb")) != NULL) read_mode = "rb"; else if ((fp = fopen ("/dev/null", "r")) != NULL) read_mode = "r"; else some sort of error; } if (fp != NULL) { if (fclose(fp) != 0 ) error; } } Personally I like wrappers for ease of porting. It doesn't bug me to see gdb_fopen + fopen on the call stack. I don't think that "rb" versus "r" can be autoconf'ed. The gdb configure script would need to execute a host program to figure out whether "rb" is supported or not, and that won't work if build != host. Or maybe I'm wrong about that and there's some way to do it. Michael