From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1476 invoked by alias); 17 Nov 2012 02:30:18 -0000 Received: (qmail 1468 invoked by uid 22791); 17 Nov 2012 02:30:17 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Nov 2012 02:30:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 97E6A2E253; Fri, 16 Nov 2012 21:30:12 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SWGoAIk0IQq4; Fri, 16 Nov 2012 21:30:12 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 67A292E251; Fri, 16 Nov 2012 21:30:12 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 7630DC26A1; Fri, 16 Nov 2012 18:30:10 -0800 (PST) Date: Sat, 17 Nov 2012 02:30:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [10/10] RFC: remove gdb_wait.h Message-ID: <20121117023010.GA9964@adacore.com> References: <87obiyzns7.fsf@fleche.redhat.com> <87wqxmwthq.fsf@fleche.redhat.com> <50A67797.7050005@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A67797.7050005@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-11/txt/msg00479.txt.bz2 > #ifndef __WCLONE > #define __WCLONE 0x80000000 /* Wait for cloned process. */ > #endif > > I'm not sure whether we still encounter systems without these, and > if gdb works on them at all. Waiting for build failure reports would > be an option. > > We could move them to say, common/linux-ptrace.h. __WALL is already there. I normally suggest that we wait for build failure reports, but your suggestion seems so simple that I'd just play it safe, and add it there. Given the flag value, I'd even venture that if __WALL is defined, I'm guessing __WCLONE should be too? -- Joel