aboutsummaryrefslogtreecommitdiff
path: root/ld/ldemul.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2016-10-18 11:42:35 +0100
committerPedro Alves <palves@redhat.com>2016-10-18 11:42:35 +0100
commitda804164742b83965b487bbff5b6334f2e63fe91 (patch)
tree15561f3d335049c3fa2e96ea752c814b04cb93cf /ld/ldemul.c
parentb928b56ea67da30216b79abd6a87ffda99fc911d (diff)
downloadgdb-da804164742b83965b487bbff5b6334f2e63fe91.zip
gdb-da804164742b83965b487bbff5b6334f2e63fe91.tar.gz
gdb-da804164742b83965b487bbff5b6334f2e63fe91.tar.bz2
Introduce gdb::unique_ptr
Many make_cleanup uses in the code base are best eliminated by using a "owning" smart pointer to manage ownership of the resource automatically. The question is _which_ smart pointer. GDB currently supports building with a C++03 compiler. We have std::auto_ptr in C++03, but, as is collective wisdom by now, that's too easy to misuse, and has therefore been deprecated in C++11 and finally removed in C++17. It'd be nice to be able to use std::unique_ptr instead, which is the modern, safe std::auto_ptr replacement in C++11. In addition to extra safety -- moving (i.e., transfer of ownership of the managed pointer between smart pointers) must be explicit -- std::unique_ptr has (among others) one nice feature that std::auto_ptr doesn't --- ability to specify a custom deleter as template parameter. In gdb's context, that allows easily creating a smart pointer for memory allocated with xmalloc -- the smart pointer then knows to release with xfree instead of delete. This is particularly interesting when managing objects allocated in C libraries, and also, for C++-fying parts of GDB that interact with other parts that still return objects allocated with xmalloc. Since std::unique_ptr's API is quite nice, and eventually we'd like to move to C++11, this patch adds a C++03-compatible smart pointer that exposes the subset of the std::unique_ptr API that we're interested in. An advantage is that whenever we start requiring C++11, we won't have to learn a new API. Meanwhile, this allows continuing to support building with a C++03 compiler. Since C++03 doesn't support rvalue references (boost gets close to emulating them, but it's not fully transparent to user code), the C++03 std::unique_ptr emulation here doesn't try hard to prevent accidentally moving, which is where most of complication of a more thorough emulation would be. Instead, we rely on the fact that GDB will be usually compiled with a C++11 compiler, and use the real std::unique_ptr in that case to catch such accidental moves. IOW, the goal here is to allow code that would be correct using std::unique_ptr to be equally correct in C++03 mode, and, just as efficient. The C++03 version was originally based on GCC 7.0's std::auto_ptr and then heavily customized to behave more like C++11's std::unique_ptr: - Support for custom (stateless) deleters. (Support for stateful deleters could be added, if necessary.) - unique_ptr<T[]> partial specialization (auto_ptr<T> does not know to use delete[]). - Support for all of 'ptr != NULL', 'ptr == NULL' and 'if (ptr)' using the safe bool idiom to emulate C++11's explicit bool operator. - There's no nullptr in C++03, so this allows initialization and assignment from NULL instead (std::auto_ptr allows neither). - Variable names un-uglified (ie., no leading __ prefix everywhere). - Formatting made to follow GDB's coding conventions, including comment style. - Converting "move" constructors done differently in order to truly support: unique_ptr<Derived> func_returning_unique_ptr (.....); ... unique_ptr<Base> ptr = func_returning_unique_ptr (.....); At this point, it no longer shares much at all with the original file, but, that's the history. See comments in the code to find out more. I thought of putting the "emulation" / shim in the "std" namespace, so that when we start requiring C++11 at some point, no actual changes to users of the smart pointer throughout would be necessary. Putting things in the std namespace is technically undefined, however in practice it doesn't cause any issue with any compiler. However, thinking that people might be confused with seeing std::unique_ptr and thinking that we're actually requiring C++11 already, I put the new types in the "gdb" namespace instead. For managing xmalloc pointers, this adds a gdb::unique_xmalloc_ptr<T> "specialization" with a custom xfree deleter. No actual use of any smart pointer is introduced in this patch. That'll be done in following patches. Tested (along with the rest of the series) on: - NetBSD 5.1 (gcc70 on the compile farm), w/ gcc 4.1.3 - x86-64 Fedora 23, gcc 5.3.1 (gnu++03) - x86-64 Fedora 23, and gcc 7.0 (gnu++14) gdb/ChangeLog: 2016-10-18 Pedro Alves <palves@redhat.com> * common/common-defs.h: Include "gdb_unique_ptr.h". * common/gdb_unique_ptr.h: New.
Diffstat (limited to 'ld/ldemul.c')
0 files changed, 0 insertions, 0 deletions