It was pointed out on IRC that the RISC-V target allocates target
descriptions and stores them in a global map, and doesn't delete these
target descriptions when GDB shuts down.
This isn't a particular problem, the total number of target
descriptions we can create is very limited so creating these on demand
and holding them for the entire run on GDB seems reasonable.
However, not deleting these objects on GDB exit means extra warnings
are printed from tools like valgrind, and the address sanitiser,
making it harder to spot real issues. As it's reasonably easy to have
GDB correctly delete these objects on exit, lets just do that.
I started by noticing that we already have a target_desc_up type, a
wrapper around unique_ptr that calls a function that will correctly
delete target descriptions, so I want to use that, but....
...that type is declared in gdb/target-descriptions.h. If I try to
include that file in gdb/arch/riscv.c I run into a problem, that file
is compiled into both GDB and GDBServer.
OK, I could guard the include with #ifdef, but surely we can do
better.
So then I decided to move the target_desc_up type into
gdbsupport/tdesc.h, this is the interface file for generic code shared
between GDB and GDBserver (relating to target descriptions). The
actual implementation for the delete function still lives in
gdb/target-description.c, but now gdb/arch/riscv.c can see the
declaration. Problem solved....
... but, though RISC-V doesn't use it I've now exposed the
target_desc_up type to gdbserver, so in future someone _might_ start
using it, which is fine, except right now there's no definition of the
delete function - remember the delete I used is only defined in GDB
code.
No problem, I add an implementation of the delete operator into
gdbserver/tdesc.cc, and all is good..... except....
I start getting this error from GCC:
tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor]
Which is caused because gdbserver's target_desc type inherits from
tdesc_element which has a virtual method, and so GCC worries that
target_desc might be used as a base class.
The solution is to declare gdbserver's target_desc class as final.
This is fine so long as we never intent to inherit from
target_desc (in gdbserver). But if we did then we'd want to make
target_desc's destructor virtual anyway, so the error above would be
resolved, and there wouldn't be an issue.
gdb/ChangeLog:
* arch/riscv.c (riscv_tdesc_cache): Change map type.
(riscv_lookup_target_description): Return pointer out of
unique_ptr.
* target-descriptions.c (allocate_target_description): Add
comment.
(target_desc_deleter::operator()): Likewise.
* target-descriptions.h (struct target_desc_deleter): Moved to
gdbsupport/tdesc.h.
(target_desc_up): Likewise.
gdbserver/ChangeLog:
* tdesc.cc (allocate_target_description): Add header comment.
(target_desc_deleter::operator()): New function.
* tdesc.h (struct target_desc): Declare as final.
gdbsupport/ChangeLog:
* tdesc.h (struct target_desc_deleter): Moved here
from gdb/target-descriptions.h, extend comment.
(target_desc_up): Likewise.
The gdbsupport directory contains a helper class print_xml_feature
that is shared between gdb and gdbserver. This class is used for
printing an XML representation of a target_desc object.
Currently this class doesn't have the ability to print the
<compatible> entities that can appear within a target description, I
guess no targets have needed that functionality yet.
The print_xml_feature classes API is based around operating on the
target_desc class, however, the sharing between gdb and gdbserver is
purely textural, we rely on their being a class called target_desc in
both gdb and gdbserver, but there is no shared implementation. We
then have a set of functions declared that operate on an object of
type target_desc, and again these functions have completely separate
implementations.
Currently then the gdb version of target_desc contains a vector of
bfd_arch_info pointers which represents the compatible entries from a
target description. The gdbserver version of target_desc has no such
information. Further, the gdbserver code doesn't seem to include the
bfd headers, and so doesn't know about the bfd types.
I was reluctant to include the bfd headers into gdbserver just so I
can reference the compatible information, which isn't (currently) even
needed in gdbserver.
So, the approach I take in this patch is to wrap the compatible
information into a new helper class. This class is declared in the
gdbsupport library, but implemented separately in both gdb and
gdbserver.
In gdbserver the class is empty. The compatible information within
the gdbserver is an empty list, of empty classes.
In gdb the class contains a pointer to the bfd_arch_info object.
With this in place we can now add support to print_xml_feature for
printing the compatible information if it is present. In the
gdbserver code this will never happen, as the gdbserver never has any
compatible information. But in gdb, this code will trigger when
appropriate.
gdb/ChangeLog:
* target-descriptions.c (class tdesc_compatible_info): New class.
(struct target_desc): Change type of compatible vector.
(tdesc_compatible_p): Update for change in type of
target_desc::compatible.
(tdesc_compatible_info_list): New function.
(tdesc_compatible_info_arch_name): New function.
(tdesc_add_compatible): Update for change in type of
target_desc::compatible.
(print_c_tdesc::visit_pre): Likewise.
gdbserver/ChangeLog:
* tdesc.cc (struct tdesc_compatible_info): New struct.
(tdesc_compatible_info_list): New function.
(tdesc_compatible_info_arch_name): New function.
gdbsupport/ChangeLog:
* tdesc.cc (print_xml_feature::visit_pre): Print compatible
information.
* tdesc.h (struct tdesc_compatible_info): Declare new struct.
(tdesc_compatible_info_up): New typedef.
(tdesc_compatible_info_list): Declare new function.
(tdesc_compatible_info_arch_name): Declare new function.
For the same reasons outlined in the previous patch, this patch renames
gdbserver source files to .cc.
I have moved the "-x c++" switch to only those rules that require it.
gdbserver/ChangeLog:
* Makefile.in: Rename source files from .c to .cc.
* %.c: Rename to %.cc.
* configure.ac: Rename server.c to server.cc.
* configure: Re-generate.
