From: Simon Marchi <simark@simark.ca>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH ?] Fix gdb build with gcc-4.8.x
Date: Tue, 18 Feb 2020 20:27:00 -0000 [thread overview]
Message-ID: <317b68d6-df81-d8e2-6e81-eb2903434ed4@simark.ca> (raw)
In-Reply-To: <AM6PR03MB5170CEC011682CCA1ABF44C6E4110@AM6PR03MB5170.eurprd03.prod.outlook.com>
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<displaced_step_closure>.
>
> 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<amd64_displaced_step_closure>’ lvalue to ‘std::unique_ptr<amd64_displaced_step_closure>&&’
> 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<amd64_displaced_step_closure>; <template-parameter-2-3> = void; _Tp = displaced_step_closure; _Dp = std::default_delete<displaced_step_closure>]’
> 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<displaced_step_closure> 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<T> &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<amd64_displaced_step_closure> 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
next parent reply other threads:[~2020-02-18 20:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AM6PR03MB5170CEC011682CCA1ABF44C6E4110@AM6PR03MB5170.eurprd03.prod.outlook.com>
2020-02-18 20:27 ` Simon Marchi [this message]
2020-02-18 21:14 ` Bernd Edlinger
2020-02-18 21:17 ` Simon Marchi
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=317b68d6-df81-d8e2-6e81-eb2903434ed4@simark.ca \
--to=simark@simark.ca \
--cc=bernd.edlinger@hotmail.de \
--cc=gdb-patches@sourceware.org \
/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