This is the mail archive of the
mailing list for the GDB project.
[pushed] Make dwarf_expr_context's destructor virtual (Re: [RFA 2/2] Make some dwarf_expr_context methods pure virtual)
- From: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Tue, 25 Oct 2016 14:59:41 +0100
- Subject: [pushed] Make dwarf_expr_context's destructor virtual (Re: [RFA 2/2] Make some dwarf_expr_context methods pure virtual)
- Authentication-results: sourceware.org; auth=none
- References: <20161025132913.E448D11C276@oc8523832656.ibm.com>
On 10/25/2016 02:29 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
>>>>>>>> "Ulrich" == Ulrich Weigand <firstname.lastname@example.org> 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:
> (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.
>From beb18c865c42ab57176099eecb65bb52e71def85 Mon Sep 17 00:00:00 2001
From: Pedro Alves <email@example.com>
Date: Tue, 25 Oct 2016 14:32:35 +0100
Subject: [PATCH] Make dwarf_expr_context's destructor virtual
Content-Type: text/plain; charset=UTF-8
$ 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]
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
2016-10-25 Pedro Alves <firstname.lastname@example.org>
* dwarf2expr.h (struct dwarf_expr_context) <~dwarf_expr_context>:
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
@@ -1,3 +1,8 @@
+2016-10-25 Pedro Alves <email@example.com>
+ * dwarf2expr.h (struct dwarf_expr_context) <~dwarf_expr_context>:
+ Make virtual.
2016-10-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
diff --git a/gdb/dwarf2expr.h b/gdb/dwarf2expr.h
index 7bf194a..3d08120 100644
@@ -68,7 +68,7 @@ struct dwarf_stack_value
- ~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);