From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25513 invoked by alias); 22 Jan 2010 14:08:34 -0000 Received: (qmail 25501 invoked by uid 22791); 22 Jan 2010 14:08:33 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jan 2010 14:08:26 +0000 Received: (qmail 32437 invoked from network); 22 Jan 2010 14:08:24 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Jan 2010 14:08:24 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [patch]: Fix build for GO32 and WIN32 targets Date: Fri, 22 Jan 2010 14:08:00 -0000 User-Agent: KMail/1.9.10 Cc: ktietz70@googlemail.com References: <90baa01f1001210612v145db5f9m3b4607f602c2ae26@mail.gmail.com> <201001212218.44673.pedro@codesourcery.com> <83sk9y7fux.fsf@gnu.org> In-Reply-To: <83sk9y7fux.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201001221408.41191.pedro@codesourcery.com> 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-01/txt/msg00547.txt.bz2 On Friday 22 January 2010 07:34:14, Eli Zaretskii wrote: > > From: Pedro Alves > > Date: Thu, 21 Jan 2010 22:18:44 +0000 > > Cc: gdb-patches@sourceware.org, ktietz70@googlemail.com > > > > I've answered your question of why don't other targets hit the same > > problem. If there's something to should be done to implement some > > missing bits for djgpp or mingw, that's a completely separate > > change. > > I never said that I objected to this change (I don't), I just wanted > to understand it, regardless. > Before Kai's patch, the code looked like static check_syscall () { ... } new_tty () { #if !defined(__GO32__) && !defined(_WIN32) check_syscall (); #endif } So, check_syscall was never called in a djgpp or win32 build of gdb. This was fine up recently, when we introduced the -Wunused-function warning, because it now warns on djgpp and win32 that check_syscall is never used. With -Werror, that warning becomes an error, so the build is broken. The fix is obvious, wrap check_syscall in `#if !defined(__GO32__) && !defined(_WIN32)' too. That's precisely, and only, what Kai's patch did. You seem to be asking why are all the calls to check_syscall compiled out on djgpp and win32. If you actually try looking at the code, and who is calling it, you'll see that this is code that runs in the context of the inferior process, not gdb, in the fork_inferior dance, when creating a new inferior. These targets don't use fork_inferior to create a process. The code is ifdefed out presumably because it wouldn't compile on those systems. -- Pedro Alves