Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: John Marshall <John.W.Marshall@glasgow.ac.uk>,
		"binutils@sourceware.org" <binutils@sourceware.org>,
		"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/3] Move gdb/common/diagnostics.h to include/diagnostics.h
Date: Mon, 04 Jun 2018 13:37:00 -0000	[thread overview]
Message-ID: <CAMe9rOqid1XEOH-LL+CQr5wQGDVALtS0i2xqm7t7-eTMPZCgbQ@mail.gmail.com> (raw)
In-Reply-To: <7570b5d9-f6c0-d9c5-3b44-34c130d13b47@redhat.com>

On Mon, Jun 4, 2018 at 6:35 AM, Pedro Alves <palves@redhat.com> wrote:
> On 06/04/2018 02:12 PM, H.J. Lu wrote:
>> On Mon, Jun 4, 2018 at 3:51 AM, John Marshall
>> <John.W.Marshall@glasgow.ac.uk> wrote:
>>> On 21 May 2018, at 13:15, H dot J dot Lu <hjl dot tools at gmail dot com> 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 <http://www.gnu.org/licenses/>.  */
>>>>
>>>> -#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.
>

I pushed my second patch and will submit a follow up patch to address
your concern on GCC version.


-- 
H.J.


      reply	other threads:[~2018-06-04 13:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 12:16 H.J. Lu
2018-05-21 13:10 ` [PATCH 2/3] Add DIAGNOSTIC_IGNORE_STRINGOP_TRUNCATION H.J. Lu
2018-06-01  7:57   ` Nick Clifton
     [not found]     ` <20180601101949.GA7660@bubble.grove.modra.org>
2018-06-01 16:51       ` H.J. Lu
2018-06-04 12:13         ` Nick Clifton
2018-06-04 12:19           ` Pedro Alves
2018-06-04 12:46             ` H.J. Lu
     [not found]               ` <CAMe9rOox6mZ6MX=GyC7-XJ2GuDzc5cjrLDyc3Hei5gBR4fWw7w@mail.gmail.com>
2018-06-04 13:40                 ` Pedro Alves
2018-06-04 14:04               ` Pedro Alves
2018-05-21 13:12 ` [PATCH 3/3] Use DIAGNOSTIC_IGNORE_STRINGOP_TRUNCATION to silence GCC 8 H.J. Lu
2018-06-01  7:59   ` Nick Clifton
2018-06-04 16:58     ` H.J. Lu
2018-06-04 17:06       ` Pedro Alves
2018-07-02 16:25       ` Tulio Magno Quites Machado Filho
2018-05-21 14:12 ` [PATCH 1/3] Move gdb/common/diagnostics.h to include/diagnostics.h Simon Marchi
2018-06-01  7:49 ` Nick Clifton
     [not found] ` <B781F464-751E-4D45-8881-36F6003759BE@glasgow.ac.uk>
2018-06-04 13:12   ` H.J. Lu
2018-06-04 13:24     ` John Marshall
2018-06-04 13:35     ` Pedro Alves
2018-06-04 13:37       ` H.J. Lu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMe9rOqid1XEOH-LL+CQr5wQGDVALtS0i2xqm7t7-eTMPZCgbQ@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=John.W.Marshall@glasgow.ac.uk \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox