5ef9273d29
This is the beginning of a series of patches where the goal is to turn the target ops vector into a class and all the target op function pointers into methods of this class. Currently, the target ops is a struct of function pointers. At the end of the series, it becomes a class with methods, and the existing low target definitions become subclasses. That is, we end up with the following class hierarchy: process_stratum_target ^ |-- linux-low |-- lynx-low |-- nto-low |-- win32-low process_stratum_target either defines the default behavior for the target ops or leaves them as pure virtual for the subclasses to override. The transformation is done by first introducing a helper class, called 'process_target', that is initially empty. An instance of this class is added to the end of the current target ops vector. This new field is called 'pt'. We will gradually carry target ops to the new class, one by one, whereas the invocation of the target op will be converted to a method call on 'pt'. For instance, target op 'attach' is currently invoked as (*the_target->attach) (args) After moving 'attach' as a method to 'process_target', it will be invoked as the_target->pt->attach (args) In this process, the concrete target vector definitions (e.g. linux-low, win32-low, nto-low, etc.) are turned into derived classes of 'process_target', so that they can either inherit the default behavior of the target ops or can override the method. We prefer to make this transition gradually rather than in a single giant patch, to yield bite-size patches. The goal is that after each patch gdbserver will still be buildable and testable. The general rule of thumb when converting a target op to a method is this: (1) If the function call is protected with a NULL-check with an obvious default behavior, simply implement that default behavior in the base class (e.g.: supports_non_stop). (2) If there is no NULL-check guard, the method becomes pure virtual, and the derived targets are required to implement the method (e.g.: attach). (3) If there is a NULL-check but no apparent default behavior, or if the NULL-check is utilized to populate a feature support packet, introduce a 'supports_XYZ' method (e.g.: pid_to_exec_file). The overall strategy is to preserve the existing behavior as much as possible. When we're done moving all the target ops into 'process_target', the target op vector will contain nothing but the field 'pt'. At that point, the auxiliary class 'process_target' will simply meld into 'process_stratum_target' and the method calls of the form 'the_target->pt->xyz' will be turned into 'the_target->xyz'. The "linux-low" target has been built and reg-tested on X86_64 Linux (Ubuntu). The "win32-low" target has been built (but not tested) via cross-compilation to a x86_64-w64-mingw32 target. The "lynx-low" and "nto-low" targets were neither built nor tested. gdbserver/ChangeLog: 2020-02-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * target.h (class process_target): New class definition. (struct process_stratum_target) <pt>: New field with type 'process_target*'. * linux-low.h (class linux_process_target): Define as a derived class of 'process_target'. * linux-low.cc (linux_target_ops): Add a linux_process_target* as the 'pt' field. * lynx-low.h (class lynx_process_target): Define as a derived class of 'process_target'. * lynx-low.cc (lynx_target_ops): Add a lynx_process_target* as the 'pt' field. * nto-low.h (class nto_process_target): Define as a derived class of 'process_target'. * nto-low.cc (nto_target_ops): Add an nto_process_target* as the 'pt' field. * win32-low.h (class win32_process_target): Define as a derived class of 'process_target'. * win32-low.cc (win32_target_ops): Add a win32_process_target* as the 'pt' field.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.