From: Pedro Alves <palves@redhat.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: [pushed] Make dwarf_expr_context's destructor virtual (Re: [RFA 2/2] Make some dwarf_expr_context methods pure virtual)
Date: Tue, 25 Oct 2016 13:59:00 -0000 [thread overview]
Message-ID: <dc51fb5b-6e64-d6c8-955c-ea60a7a681cc@redhat.com> (raw)
In-Reply-To: <20161025132913.E448D11C276@oc8523832656.ibm.com>
On 10/25/2016 02:29 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
>>>>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
>>>
>>> Ulrich> This seems to have broken my SPU daily build (running on RHEL 5 with a
>>> Ulrich> GCC 4.1 system compiler):
>>
>> Any chance you could install the newer GCC from DTS on that machine?
>
> I don't think there even is a DTS for RHEL 5 on Power, or has that changed?
Whoops, you're right. Sorry, missed that.
>> Otherwise, if/when we go C++11, that builder will stop working.
>
> Well, once GDB officially no longer supports building with GCC 4.1, I'll
> have to come up with another solution; I'll probably just build my own
> compiler then. However, as long as GCC 4.1 *is* supported, I think it
> is a good to actually still have a system testing that.
Agreed. I'd like to move forward with requiring C++11 soon though.
I was mainly giving it some more time:
https://sourceware.org/ml/gdb-patches/2016-10/msg00607.html
> (In any case, I'm not sure how long it makes sense to keep the Cell SPU
> daily build up and running, given that RHEL 5 is about to go out of
> service anyway and more recent distros no longer support Cell ...)
It's up to you of course. As we chatted on the Cauldron, it's unfortunate
since that's the best way we have to avoid multi-arch support from bit rotting.
I'd like to see gdb move in the direction of supporting seamless
remote-procedure calls. E.g., following an RPC call across
32-bit client x 64-bit server and back, even on the same machine.
Seamless CPU+GPU debugging support likely will take advantage of
it as well in the future. So maybe we'll gain back testing
some other way.
>
>> In file included from .../src/gdb/dwarf2expr.c:28:0:
>> .../src/gdb/dwarf2expr.h:68:8: warning: ‘struct dwarf_expr_context’ has virtual functions and accessible non-virtual destructor [-Wnon-virtual-dtor]
>> struct dwarf_expr_context
>> ^~~~~~~~~~~~~~~~~~
>>
>> I'll add the "virtual" in a bit.
>
> Thanks!
Pushed now.
From beb18c865c42ab57176099eecb65bb52e71def85 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 25 Oct 2016 14:32:35 +0100
Subject: [PATCH] Make dwarf_expr_context's destructor virtual
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Ref: https://sourceware.org/ml/gdb-patches/2016-10/msg00662.html
$ make WERROR_CFLAGS="-Wnon-virtual-dtor" dwarf2expr.o
...
In file included from .../src/gdb/dwarf2expr.c:28:0:
.../src/gdb/dwarf2expr.h:68:8: warning: ‘struct dwarf_expr_context’ has virtual functions and accessible non-virtual destructor [-Wnon-virtual-dtor]
struct dwarf_expr_context
^~~~~~~~~~~~~~~~~~
Happens to not be a problem in practice currently because concrete
subclasses are allocated on the stack. I.e., we don't ever delete
objects of types that derive from dwarf_expr_context through pointers
to dwarf_expr_context.
gdb/ChangeLog:
2016-10-25 Pedro Alves <palves@redhat.com>
* dwarf2expr.h (struct dwarf_expr_context) <~dwarf_expr_context>:
Make virtual.
---
gdb/ChangeLog | 5 +++++
gdb/dwarf2expr.h | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 10d6866..91f36f9 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2016-10-25 Pedro Alves <palves@redhat.com>
+
+ * dwarf2expr.h (struct dwarf_expr_context) <~dwarf_expr_context>:
+ Make virtual.
+
2016-10-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
PR build/20712
diff --git a/gdb/dwarf2expr.h b/gdb/dwarf2expr.h
index 7bf194a..3d08120 100644
--- a/gdb/dwarf2expr.h
+++ b/gdb/dwarf2expr.h
@@ -68,7 +68,7 @@ struct dwarf_stack_value
struct dwarf_expr_context
{
dwarf_expr_context ();
- ~dwarf_expr_context ();
+ virtual ~dwarf_expr_context ();
void push_address (CORE_ADDR value, int in_stack_memory);
void eval (const gdb_byte *addr, size_t len);
--
2.5.5
next prev parent reply other threads:[~2016-10-25 13:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-20 21:51 [RFA 0/2] c++ patch follow-ups Tom Tromey
2016-10-20 21:51 ` [RFA 2/2] Make some dwarf_expr_context methods pure virtual Tom Tromey
2016-10-20 22:21 ` Pedro Alves
2016-10-24 12:28 ` Ulrich Weigand
2016-10-24 13:36 ` Tom Tromey
2016-10-25 13:22 ` Pedro Alves
2016-10-25 13:29 ` Ulrich Weigand
2016-10-25 13:59 ` Pedro Alves [this message]
2016-10-25 13:47 ` Tom Tromey
2016-10-25 14:05 ` Pedro Alves
2016-10-25 16:25 ` Trevor Saunders
2016-10-25 16:57 ` Pedro Alves
2016-10-20 21:51 ` [RFA 1/2] Change minimal_symbol_reader::record_full to take a bool Tom Tromey
2016-10-20 22:14 ` Pedro Alves
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=dc51fb5b-6e64-d6c8-955c-ea60a7a681cc@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
--cc=uweigand@de.ibm.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