From patchwork Tue Feb 18 19:06:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 38214 Received: (qmail 54951 invoked by alias); 18 Feb 2020 19:06:11 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 54942 invoked by uid 89); 18 Feb 2020 19:06:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-20.7 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy=1515, 1514, HX-Spam-Relays-External:e400, CXX X-HELO: EUR05-VI1-obe.outbound.protection.outlook.com Received: from mail-vi1eur05olkn2046.outbound.protection.outlook.com (HELO EUR05-VI1-obe.outbound.protection.outlook.com) (40.92.90.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 19:06:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BUpM+n0DK+8ylsg/TQx0gprVioo3GHlPEWIqh2V+tMgztcAQVjXsWeA+9jQN4j8A6RvxZClpNS5D+UgxiGeQdL1RnUNet8hJCSx54IP86jsVdXP2inahnq9JOkzyZMFo64BtjDUa5c6NlhxbL6u5rNICr8b7yVolcdSqEY3TM+cGdE6pal9vuKCfnvk0ZIJT/NzUl84EXaDdJrmHt+mSoGSGzfZs+xiW2c9V1cn/6aQ2D1nthq3OlCKMZL+dpKEvWmK8kacd74xJq0rPBMgCSok+fAm/HRmimdVcbk9PaKwQsxb+A9XYFsU2nZATo7Pb0AQEeG/Bp0Cd3WhIn0NMhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iVWo8sD+9sxaZIiFwRmO90kVMM9Ie2kJrvIoLnhD3NI=; b=A6KvyYZRyUrZ+i8tPwX+obJBfB3dNoXgV4R1m3ewevVb5G0jp8IUzF0iF56P4npyfIqQTzMK0Gh8E7ZJ/YBVRuUFNpA8j35hOQ1KHWFxvRXS8r7L85AOAfzyzh8LXWORkjPwlogfTcHNdTKMxFtqSP7pvV5rxKRs6oX1I5egZZVge62i1/ll1eBxDx5MMzCYsHs1bu+zPmE2kIrP8TO5votd3jkRmmxFYQctfAPYFSqWHOHamAJlLtMZkz2fT6VuCSSIeVKGDA5l2tmtybQ8GiajmFBdX9VUOug/WsI3LiNFTCw7zNCRPz0IrgpxyYW7txFmT/5VR+oebtsfvA1pZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM6EUR05FT031.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::35) by AM6EUR05HT167.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::395) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22; Tue, 18 Feb 2020 19:06:06 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.233.240.57) by AM6EUR05FT031.mail.protection.outlook.com (10.233.240.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22 via Frontend Transport; Tue, 18 Feb 2020 19:06:06 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd%6]) with mapi id 15.20.2729.032; Tue, 18 Feb 2020 19:06:06 +0000 Received: from [192.168.1.101] (92.77.140.102) by FR2P281CA0025.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.23 via Frontend Transport; Tue, 18 Feb 2020 19:06:05 +0000 From: Bernd Edlinger To: "gdb-patches@sourceware.org" , Simon Marchi Subject: [PATCH ?] Fix gdb build with gcc-4.8.x Date: Tue, 18 Feb 2020 19:06:06 +0000 Message-ID: x-microsoft-original-message-id: <8eb22bee-a059-bf91-a85b-7080a44e508f@hotmail.de> x-ms-exchange-antispam-messagedata: BGW7LVtWK7RpwkEhJzJOpfww1gLa54py/EkQ5tTudDDzbTrfgivvsczxYjzJHIWCBC3zC8PiFvsz5qIWgpBZ5UDoWx/BzlG0IwB6OZCa4Lg7OkACxVntjKpw+9mQpBYFGCPPDPNaG7bI2VLqU9Q7Rg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 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. From 493f67826232f0c4dab3a6bf69f851d01616e75f Mon Sep 17 00:00:00 2001 From: Bernd Edlinger Date: Sun, 16 Feb 2020 22:55:55 +0100 Subject: [PATCH] Fix build with gcc-4.8.x MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Make displaced_step_closure_up a wrapper class around unique_ptr to avoid compiler bugs with implicit casting from derived unique_ptr to displaced_step_closure_up observed with with gcc-4.8.4: ../../binutils-gdb/gdb/amd64-tdep.c:1514:10: error: cannot bind ‘std::unique_ptr’ lvalue to ‘std::unique_ptr&&’ gdb: 2020-02-16 Bernd Edlinger * infrun (displaced_step_closure_up): Convert to a wrapper class. --- gdb/infrun.h | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/gdb/infrun.h b/gdb/infrun.h index 625c53a..49566ed 100644 --- a/gdb/infrun.h +++ b/gdb/infrun.h @@ -265,7 +265,23 @@ struct displaced_step_closure virtual ~displaced_step_closure () = 0; }; -using displaced_step_closure_up = std::unique_ptr; +/* A wrapper class around std::unique_ptr. + Technically unnecessary, but helps avoiding a compiler bug. */ + +struct displaced_step_closure_up : std::unique_ptr +{ + displaced_step_closure_up () + {} + + template + displaced_step_closure_up (std::unique_ptr &up) + : std::unique_ptr (up.release ()) + {} + + displaced_step_closure_up (displaced_step_closure *up) + : std::unique_ptr (up) + {} +}; /* A simple displaced step closure that contains only a byte buffer. */ -- 1.9.1