From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26268 invoked by alias); 7 Mar 2019 18:20:16 -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 26257 invoked by uid 89); 7 Mar 2019 18:20:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_00,KAM_SHORT,LIKELY_SPAM_BODY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=HX-Languages-Length:1495 X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Mar 2019 18:20:14 +0000 Received: by mail-wr1-f65.google.com with SMTP id o17so18606068wrw.3 for ; Thu, 07 Mar 2019 10:20:14 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4c97:6d52:2cea:997b? ([2001:8a0:f913:f700:4c97:6d52:2cea:997b]) by smtp.gmail.com with ESMTPSA id n14sm5793518wrx.24.2019.03.07.10.20.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 10:20:12 -0800 (PST) Subject: Re: MinGW build failure for GDB 8.2.90 with source-highlight To: Simon Marchi References: <83r2bibvlv.fsf@gnu.org> <10c9e85f-d216-ef5c-c8ca-636331d0d1ba@redhat.com> <353a11fc68f77c293d7b706586b06724@polymtl.ca> Cc: Eli Zaretskii , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <735b109f-4ae4-5993-57f0-eb548752fc23@redhat.com> Date: Thu, 07 Mar 2019 18:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <353a11fc68f77c293d7b706586b06724@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-03/txt/msg00163.txt.bz2 On 03/07/2019 06:09 PM, Simon Marchi wrote: > On 2019-03-07 12:11, Pedro Alves wrote: >> On 03/07/2019 04:59 PM, Simon Marchi wrote: >> >>> I don't recall what's the long term solution for this.  We could use gnulib's namespace support [2], but the disadvantage is that we would need to use gnulib::some_function (assuming we name the namespace "gnulib") instead of just some_function to use the "fixed" version.  If we use some_function directly, it will use the buggy version on those systems where it is buggy. >> >> Wrap all of gdb in a namespace.  Recall that this was what led to C++ >> wildmatching support. > > I don't understand how this will help. Sorry, I thought the reference would make you recall the previous discussions. See below. > If you have > > #define open rpl_open > > namespace gdb { >   struct target_ops { >     void open(); >   } > } > > The macro will still wrongfully replace open. See slides #16-#17 of my Cauldron 2017 presentation: https://gcc.gnu.org/wiki/cauldron2017?action=AttachFile&do=view&target=gdb+-+C%2B%2B+conversion+%26+dogfood.pdf The idea is to put all of gdb under "namespace gdb", and also put gnulib in the same namespace, using gnulib's namespace support. That way, there are no macros, and, the code looks just like it does today, except for the "namespace gdb" wrapping. Prototyped here: https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace Thanks, Pedro Alves