From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 3409E385741F for ; Tue, 15 Jun 2021 11:10:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3409E385741F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 271F9B6D13; Tue, 15 Jun 2021 13:10:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YZRJwcPaDSj; Tue, 15 Jun 2021 13:10:25 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p50854661.dip0.t-ipconnect.de [80.133.70.97]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id BF26EB68AA; Tue, 15 Jun 2021 13:10:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1623755425; bh=o93E1AZCmBbipd1rTJz/vFY+pLBrVafGcnRZIwh5le4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FVkSuz3OwIqTRhmS75c2/A3CP0ntAzCxBL6H3fJQSEItWF5/SQl9Inz6Ch6GtlTCm JhsWMhrDoHA+//RqlEtJYUD0KdJvrKa8YdvWvCl+6nYbLj0ba+PdHP4dP59GcxQWXu c3yVLP+JbMu3enzukAqpGUYQjAw0sVn3D/Ljv8Pk0GvG1Hn74wI1JaZnxRHzWqs4G9 yUQG/tfGFP2U3nCwQ291FOdhXLVaEJ8SwVKioNMHNR4RKBeXJkrBHxgzI4aJu12zit N2UCBXvtRC1hjygemm9hXd8hjcymLQAsTPs+5BXffN2hI4Ov3rDLmOzYEBcayaHre8 t5iG0wPreivGg== From: Rainer Orth To: Tom Tromey Cc: Bernd Edlinger , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Fix gdb crash due to SIGPIPE when the compile command fails References: <87tumgp1ob.fsf@tromey.com> <87zgw5oijf.fsf@tromey.com> <87mtrsfprp.fsf@tromey.com> Date: Tue, 15 Jun 2021 13:10:25 +0200 In-Reply-To: <87mtrsfprp.fsf@tromey.com> (Tom Tromey's message of "Mon, 14 Jun 2021 09:07:54 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3787.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 11:10:28 -0000 Hi Tom, > Rainer> that's what I've been using myself to fix the build locally. However, > Rainer> as I said I'm completely uncertain if that's the right fix, especially > Rainer> given that gdb/compile files don't include any system headers directly. > > That must just be happenstance. > > Normally, a universally-available system header can be included > anywhere. Sometimes there is a wrapper header, and so in these cases > one ought to use the wrapper instead. There's no particular ordering of > headers, except that defs.h (gdbsupport and gdbserver have similar, but > differently-named headers) must come first. (We looked into a script to > reorder headers but I never finished ironing out the bugs.) ah, thanks for the clarification. I guess I must have been thinking of gcc's system.h which centralizes the inclusion of many system headers, dealing with platform-specific quirks along the way. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University