From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102266 invoked by alias); 4 Jun 2018 13:35:55 -0000 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 Received: (qmail 101560 invoked by uid 89); 4 Jun 2018 13:35:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=diagnostic_push, JohnWMarshallglasgowacuk, johnwmarshallglasgowacuk, John.W.Marshall@glasgow.ac.uk X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Jun 2018 13:35:53 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D940440122AC; Mon, 4 Jun 2018 13:35:51 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id E9443200BCEB; Mon, 4 Jun 2018 13:35:50 +0000 (UTC) Subject: Re: [PATCH 1/3] Move gdb/common/diagnostics.h to include/diagnostics.h To: "H.J. Lu" , John Marshall References: <20180521121557.16535-1-hjl.tools@gmail.com> Cc: "binutils@sourceware.org" , "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <7570b5d9-f6c0-d9c5-3b44-34c130d13b47@redhat.com> Date: Mon, 04 Jun 2018 13:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00062.txt.bz2 On 06/04/2018 02:12 PM, H.J. Lu wrote: > On Mon, Jun 4, 2018 at 3:51 AM, John Marshall > wrote: >> On 21 May 2018, at 13:15, H dot J dot Lu wrote: >>> Move gdb/common/diagnostics.h to include/diagnostics.h so that it can >>> be used in binutils. >> >> This patch broke building gdb on MacOS with clang (i.e., after ./configure with no options): >> >> CXX gdb.o >> In file included from ../../../binutils-gdb/gdb/gdb.c:19: >> In file included from ../../../binutils-gdb/gdb/defs.h:531: >> In file included from ../../../binutils-gdb/gdb/gdbarch.h:39: >> In file included from ../../../binutils-gdb/gdb/frame.h:72: >> In file included from ../../../binutils-gdb/gdb/language.h:26: >> ../../../binutils-gdb/gdb/symtab.h:1361:1: error: _Pragma takes a parenthesized string literal >> DEF_VEC_P (symtab_ptr); I think clang is printing a bogus location here. symtab.h includes vec.h, which includes diagnostics.h and does: /* clang has a bug that makes it warn (-Wunused-function) about unused functions that are the result of the DEF_VEC_* macro expansion. See: https://bugs.llvm.org/show_bug.cgi?id=22712 We specifically ignore this warning for the vec functions when the compiler is clang. */ #ifdef __clang__ # define DIAGNOSTIC_IGNORE_UNUSED_VEC_FUNCTION \ DIAGNOSTIC_IGNORE_UNUSED_FUNCTION #else # define DIAGNOSTIC_IGNORE_UNUSED_VEC_FUNCTION #endif and that's most certainly what is tripping on the _Pragma+STRINGIFY. >> >>> --- a/gdb/common/diagnostics.h >>> +++ b/include/diagnostics.h >>> [snip] >>> @@ -15,10 +13,8 @@ >>> You should have received a copy of the GNU General Public License >>> along with this program. If not, see . */ >>> >>> -#ifndef COMMON_DIAGNOSTICS_H >>> -#define COMMON_DIAGNOSTICS_H >>> - >>> -#include "common/preprocessor.h" >> >> Putting this #include back fixes the build. Apparently in this configuration, include/diagnostics.h doesn't otherwise have a definition of STRINGIFY whereas on Linux or other platforms it does, via some coincidence of different host-related includes or something. > > Please add > > #include "common/preprocessor.h" > > to gdb.c. > I don't think so, see above. Where does binutils get the definition of STRINGIFY from? Your other patch does: > --- a/include/diagnostics.h > +++ b/include/diagnostics.h > @@ -19,8 +19,13 @@ > #ifdef __GNUC__ > # define DIAGNOSTIC_PUSH _Pragma ("GCC diagnostic push") > # define DIAGNOSTIC_POP _Pragma ("GCC diagnostic pop") > + > +/* Stringification. */ > +# define DIAGNOSTIC_STRINGIFY_1(x) #x > +# define DIAGNOSTIC_STRINGIFY(x) DIAGNOSTIC_STRINGIFY_1 (x) > + > # define DIAGNOSTIC_IGNORE(option) \ > - _Pragma (STRINGIFY (GCC diagnostic ignored option)) > + _Pragma (DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored option)) > #else So I'm surprised by your suggestion. That DIAGNOSTIC_STRINGIFY bit should be split out of that other patch and pushed in separately, IMO. Alternatively, preprocessor.h should be shared too. Thanks, Pedro Alves