From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11701 invoked by alias); 18 Aug 2004 15:31:25 -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 11677 invoked from network); 18 Aug 2004 15:31:22 -0000 Received: from unknown (HELO hall.mail.mindspring.net) (207.69.200.60) by sourceware.org with SMTP; 18 Aug 2004 15:31:22 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BxSP9-0006Zt-00; Wed, 18 Aug 2004 11:31:11 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 88E324B102; Wed, 18 Aug 2004 11:31:10 -0400 (EDT) Date: Wed, 18 Aug 2004 15:31:00 -0000 From: Michael Chastain To: gdb-patches@sources.redhat.com, baurzhan.ismagulov@sbs.com.tr Subject: Re: testcase for "absolute source" patch Message-ID: <4123763C.nailM3P11DT7E@mindspring.com> References: <20040816144349.GB1509@ata.cs.hun.edu.tr> <412107B7.nailE7I1XJVIH@mindspring.com> <20040818130626.GB1411@ata.cs.hun.edu.tr> In-Reply-To: <20040818130626.GB1411@ata.cs.hun.edu.tr> 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-08/txt/msg00556.txt.bz2 Hi Baurzhan, bi> 1. Just for my knowledge: I've found the "int main" requirement in C99 bi> 5.1.2.2.1. But I couldn't find anything about function definitions bi> without a return type defaulting to int (i.e., should the compiler bi> treat the return type as int if it isn't specified?). Does C99 and bi> previous standards say anything about that? Is it different for bi> declarations and definitions? I don't have copies of the standards documents, so I'm working from The C++ Programming Language 2nd Edition, Kernighan and Ritchie. To my surprise, I found out that in this book, and presumably in the C89 standard, a function with no return type defaults to "int". >From section 1.9: "This line also declares that getline returns an int; since int is the default return type, it could be omitted." I don't think it's different for declarations and definitions. In a normal program, the FSF coding standards would apply. But a test suite is contra-variant. Anything that is legal C89 and that doesn't make gcc give a warning is okay in a test program, and variation is good because it exercises different parts of gdb. So it's okay to leave your "main" with no return type. But take out the "-w" from gdb_compile. bi> 2. As far as I could see, remote_exec host starts a new shell each time. bi> How should one do the following right? bi> bi> remote_exec host cd ... bi> remote_exec host gdb_compile ... bi> remote_exec host cd ... bi> bi> I'm reluctant to write scripts since I have to do the same with bi> gdb_test, too. I don't know. Dejagnu's desire to manage the filenames on the host machine conflicts with your desire for explicit control of the filenames. Normally you would call gdb_compile (not remote_exec host gdb_compile). gdb_compile calls target_compile, which calls default_target_compile, which calls remote_exec, which calls call_remote. You would need a hook inside call_remote to send several commands to the same shell. Ick! Alternatively, you would need to forsake gdb_compile and do everything at the "remote_exec host cd ... && gcc ... && cd ...", basically duplicating the machinery inside default_target_compile to process the options (but you know what your own options are) and to find the name of the c compiler. I have another issue which demands that I clean up the machinery that locates compilers. The issue is how to run the test suite with non-fsf compilers, especially for fortran. Let me think about this, and I will get back to tonight or tomorrow, also with detailed feedback on your version #2. Michael