From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128923 invoked by alias); 18 Feb 2020 20:27:23 -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 128913 invoked by uid 89); 18 Feb 2020 20:27:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:AM6PR03, H*i:sk:AM6PR03 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 20:27:21 +0000 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C75501E5FA; Tue, 18 Feb 2020 15:27:19 -0500 (EST) Subject: Re: [PATCH ?] Fix gdb build with gcc-4.8.x To: Bernd Edlinger , "gdb-patches@sourceware.org" References: From: Simon Marchi Message-ID: <317b68d6-df81-d8e2-6e81-eb2903434ed4@simark.ca> Date: Tue, 18 Feb 2020 20:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2020-02/txt/msg00735.txt.bz2 On 2020-02-18 2:06 p.m., Bernd Edlinger wrote: > Hi, > > I noticed that gdb cannot be built any more with gcc-4.8.4 > since Simon's patch which introduced the > std::unique_ptr. > > The failure mode is as follows: > > CXX amd64-tdep.o > ../../binutils-gdb/gdb/amd64-tdep.c: In function ‘displaced_step_closure_up amd64_displaced_step_copy_insn(gdbarch*, CORE_ADDR, CORE_ADDR, regcache*)’: > ../../binutils-gdb/gdb/amd64-tdep.c:1514:10: error: cannot bind ‘std::unique_ptr’ lvalue to ‘std::unique_ptr&&’ > return dsc; > ^ > In file included from /usr/include/c++/4.8/memory:81:0, > from ../../binutils-gdb/gdb/../gdbsupport/common-exceptions.h:25, > from ../../binutils-gdb/gdb/../gdbsupport/common-defs.h:140, > from ../../binutils-gdb/gdb/defs.h:28, > from ../../binutils-gdb/gdb/amd64-tdep.c:22: > /usr/include/c++/4.8/bits/unique_ptr.h:169:2: error: initializing argument 1 of ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(std::unique_ptr<_Up, _Ep>&&) [with _Up = amd64_displaced_step_closure; _Ep = std::default_delete; = void; _Tp = displaced_step_closure; _Dp = std::default_delete]’ > unique_ptr(unique_ptr<_Up, _Ep>&& __u) noexcept > ^ > ../../binutils-gdb/gdb/amd64-tdep.c:1515:1: error: control reaches end of non-void function [-Werror=return-type] > } > ^ > cc1plus: all warnings being treated as errors > > > It continues to work with gcc-5.4.0, though. I don't know what > is with gcc-4.9.x. > > I have two possible workarounds for this attached to this as > variant-1 patch and variant-2 patch respectively. I personally > would prefer variant-2 which makes displaced_step_closure_up a > wrapper class around unique_ptr and > avoids to trigger this compiler bug by being slightly simpler as > the original, I think the issue always starts when the argument > to displaced_step_closure_up (std::unique_ptr &up) is > using double-ampersand. > > So we have three possible ways to deal with this: > variant-1: simplify the code where the type cast happens, > variant-2: use a simplified wrapper clase, and > variant-3: do nothing about it, and document that gcc-5.4.0 is > or newer is required. > > What do you think? > > > Thanks > Bernd. > Hi Bernd, I don't like variant 2, because it changes the API/contract of std::unique_ptr. It allows doing std::unique_ptr dsc; displaced_step_closure_up hello (dsc); Which would not be possible if displaced_step_closure_up was a simple typedef. In our code base, the types that end with _up are known to be typedefs to std::unique_ptr, and I don't think it would be a good idea to provide such a type with a semantic that differs from std::unique_ptr. So I would prefer something along the lines of variant 1, but with a small comment at each site saying that this is to work around a problem with g++ 4.8. Thanks, Simon