Differences between revisions 1 and 17 (spanning 16 versions)
Revision 1 as of 2011-05-16 04:30:49
Size: 1824
Editor: YaoQi
Comment:
Revision 17 as of 2013-07-31 12:07:11
Size: 5079
Editor: PedroAlves
Comment: shuffle things around, remove "Plan"; remove speculation bits; add "Arch-specific bits of the target backends".
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma section-numbers 2
Line 2: Line 3:
This page describes the work to move common code of GDB and GDBserver to files in common/ directory. <<TableOfContents>>

This page describes the work to move duplicate code of GDB and GDBserver to files in the gdb/common/ directory.
Line 5: Line 8:
The goal of this project is to reduce the code duplication between GDB and GDBserver, and to signify the stuffs in common directory. There's a lot of code duplication between GDB and GDBserver. The project has been taking baby steps in reducing such duplication, by putting shared code in the gdb/common/ directory. The goal of this project is to reduce the duplication as much as possible, and to signify the contents of the gdb/common/ directory.
Line 7: Line 10:
== Plan ==
Here is something like a plan on what we can do on this project,
== Where's the duplication then? ==
Line 10: Line 12:
* Move duplicated code among *-nat.c and *-low.c. Some macros, and code accessing hardware registers should be the same on both GDB and GDBserver. No reason to keep the same code in two copies respectively. Move these duplicated part to common/ directory, and give a logically reasonable file name. For example, the code for accessing debug registers are duplicated in i386-low.c and i386-nat.c, so they can be moved to common directory with file name i386-dbg-reg.c and i386-rdbg-reg.h. See [[http://sourceware.org/ml/gdb-patches/2011-03/msg00648.html| Move common macros to i386-dbg-reg.h]]. There is no automatic way to identify the duplications between *-nat.c and *-low.c except examining code manually. === Target backends ===
Line 12: Line 14:
* Move gdb_thread_db.h and gdb_wait.h to common directory. gdb/gdb_thread_db.h is include by both GDB and GDBserver, so it is straightforward to move gdb_thread_db.h to common/ dir. gdb_wait.h can be moved to common dir as well, as discussed [[http://sourceware.org/ml/gdb-patches/2011-04/msg00509.html|here]]. These are the biggest duplication offenders. That is, the gdb/*-nat.c files and the gdb/gdbserver/*-low.c files accomplish pretty much the same. (Some targets do things differently enough, that they're not really duplication of code, but can be considered different implementations. The Linux support is one such case. Over the years we've been converging them though -- see the [[LocalRemoteFeatureParity]] page for more details.). GDBserver supports fewer target OSs than GDB does. Ideally, we'd finish the [[LocalRemoteFeatureParity]] project first, and then just dump the GDB-side backends. Presently, there's overlap/duplication in:
Line 14: Line 16:
* Move duplicated code utils.c and gdbserver/utils.c. So far, there are two instance of implementations to functions like xmalloc, xrealloc, internal_error, etc. They are not 100% the same, but can be moved to common/utils.c    * Linux
Line 16: Line 18:
* Move duplicated code in gdb/linux-thread-db.c and gdb/gdbserver/thread-db.c. There should be some duplications, but still no idea on how to, due to lack of knowledge on these two files.      See the [[LocalRemoteFeatureParity]] page for more details.

     || GDB || GDBserver ||
     || gdb/linux-nat.c || gdb/gdbserver/linux-low.c ||
     || gdb/proc-service.c || gdb/gdbserver/proc-service.c ||
     || gdb/linux-thread-db.c || gdb/gdbserver/thread-db.c ||
     || ... and related arch specific files ... || ||

   * Windows

     || GDB || GDBserver ||
     || gdb/windows-nat.c || gdb/gdbserver/win32-low.c ||
     || ... and related arch specific files ... || ||

   * NTO

     || GDB || GDBserver ||
     || gdb/nto-procfs.c || gdb/gdbserver/nto-low.c ||
     || ... and related arch specific files ... || ||

=== Arch-specific bits of the target backends ===

Independently of the local/remote parity project, however, there are bits of the backends, most prominently, the arch specific bits, that can be shared between the target backend implementations before then, as the interfaces are similar enough. E.g., code accessing hardware registers, debug registers/watchpoint support; code that detects which variant of a processor the program is running (the xml target description to send to GDB core), etc.. Sharing such arch specific code significantly reduces the effort for new ports (those usually don't need to touch common code). As is today most ports involve doing the same work twice. We should clean up some of the existing ports, laying grounds for good examples for new ports.

Move these duplicated part to common/ directory, and give come up with logically reasonable file names. For example, the code for accessing debug registers are duplicated in gdbserver/i386-low.c and i386-nat.c, so they can be moved to common directory with file name i386-dbg-reg.c and i386-rdbg-reg.h. See [[http://sourceware.org/ml/gdb-patches/2011-03/msg00648.html| Move common macros to i386-dbg-reg.h]].

=== Terminal handling ===

Parts of terminal handling are duplicated.

|| GDB || GDBserver || comments ||
|| gdb/terminal.h || gdb/gdbserver/terminal.h || (parts) ||

=== Event loop machinery ===

|| GDB || GDBserver || comments ||
|| gdb/event-loop.c || gdb/gdbserver/event-loop.c || ||

=== Build/Configure machinery ===

|| GDB || GDBserver || comments ||
|| gdb/configure.ac, etc. || gdb/gdbserver/configure.ac, etc. || ||

So far, we have three possible approaches to address this:

 1. Don't have its own build stuff in common/, let gdb or gdbserver pick the pieces they want, and duplicate the necessary autoconf checks, etc.. This is the status quo.
 2. Make common/ have its own configure. In March 2011, Yao gave a try to build common/ as a library (libcommon.a), for both GDB and GDBserver to link. See the thread [[http://sourceware.org/ml/gdb-patches/2011-02/msg00209.html|here]]. The patches went into CVS, but were later reverted, because of various issues they caused.
 3. Create Makefile fragments and m4 files in common/, then sourced by gdb and gdbserver's build machineries. No new configure. This is the direction we're heading towards now. See [[http://sourceware.org/ml/gdb-patches/2013-04/msg00739.html|this thread (RFC: introduce common.m4)]].

== Guidelines ==

=== File Naming ===

  * Avoid "common" in file names in files under common/. Instead, name the files for what they contain, not for the fact that they're "common" to two programs (gdb, gdbserver) presently. The preferred direction is, when moving things to common/, take the opportunity to split them into smaller, more atomic, leaner units. E.g., that's how we ended up with ptid.h/ptid.c, instead of inferior-common.h (or some such). If the resulting file is just a dumping ground of miscellaneous things, then call it that. Say, foo-misc.h or foo-defs.h, not foo-common.h.

----

OngoingWork
LocalRemoteFeatureParity

Common part of GDB and GDBserver

This page describes the work to move duplicate code of GDB and GDBserver to files in the gdb/common/ directory.

1. Goal

There's a lot of code duplication between GDB and GDBserver. The project has been taking baby steps in reducing such duplication, by putting shared code in the gdb/common/ directory. The goal of this project is to reduce the duplication as much as possible, and to signify the contents of the gdb/common/ directory.

2. Where's the duplication then?

2.1. Target backends

These are the biggest duplication offenders. That is, the gdb/*-nat.c files and the gdb/gdbserver/*-low.c files accomplish pretty much the same. (Some targets do things differently enough, that they're not really duplication of code, but can be considered different implementations. The Linux support is one such case. Over the years we've been converging them though -- see the LocalRemoteFeatureParity page for more details.). GDBserver supports fewer target OSs than GDB does. Ideally, we'd finish the LocalRemoteFeatureParity project first, and then just dump the GDB-side backends. Presently, there's overlap/duplication in:

  • Linux
    • See the LocalRemoteFeatureParity page for more details.

      GDB

      GDBserver

      gdb/linux-nat.c

      gdb/gdbserver/linux-low.c

      gdb/proc-service.c

      gdb/gdbserver/proc-service.c

      gdb/linux-thread-db.c

      gdb/gdbserver/thread-db.c

      ... and related arch specific files ...

  • Windows
    • GDB

      GDBserver

      gdb/windows-nat.c

      gdb/gdbserver/win32-low.c

      ... and related arch specific files ...

  • NTO
    • GDB

      GDBserver

      gdb/nto-procfs.c

      gdb/gdbserver/nto-low.c

      ... and related arch specific files ...

2.2. Arch-specific bits of the target backends

Independently of the local/remote parity project, however, there are bits of the backends, most prominently, the arch specific bits, that can be shared between the target backend implementations before then, as the interfaces are similar enough. E.g., code accessing hardware registers, debug registers/watchpoint support; code that detects which variant of a processor the program is running (the xml target description to send to GDB core), etc.. Sharing such arch specific code significantly reduces the effort for new ports (those usually don't need to touch common code). As is today most ports involve doing the same work twice. We should clean up some of the existing ports, laying grounds for good examples for new ports.

Move these duplicated part to common/ directory, and give come up with logically reasonable file names. For example, the code for accessing debug registers are duplicated in gdbserver/i386-low.c and i386-nat.c, so they can be moved to common directory with file name i386-dbg-reg.c and i386-rdbg-reg.h. See Move common macros to i386-dbg-reg.h.

2.3. Terminal handling

Parts of terminal handling are duplicated.

GDB

GDBserver

comments

gdb/terminal.h

gdb/gdbserver/terminal.h

(parts)

2.4. Event loop machinery

GDB

GDBserver

comments

gdb/event-loop.c

gdb/gdbserver/event-loop.c

2.5. Build/Configure machinery

GDB

GDBserver

comments

gdb/configure.ac, etc.

gdb/gdbserver/configure.ac, etc.

So far, we have three possible approaches to address this:

  1. Don't have its own build stuff in common/, let gdb or gdbserver pick the pieces they want, and duplicate the necessary autoconf checks, etc.. This is the status quo.
  2. Make common/ have its own configure. In March 2011, Yao gave a try to build common/ as a library (libcommon.a), for both GDB and GDBserver to link. See the thread here. The patches went into CVS, but were later reverted, because of various issues they caused.

  3. Create Makefile fragments and m4 files in common/, then sourced by gdb and gdbserver's build machineries. No new configure. This is the direction we're heading towards now. See this thread (RFC: introduce common.m4).

3. Guidelines

3.1. File Naming

  • Avoid "common" in file names in files under common/. Instead, name the files for what they contain, not for the fact that they're "common" to two programs (gdb, gdbserver) presently. The preferred direction is, when moving things to common/, take the opportunity to split them into smaller, more atomic, leaner units. E.g., that's how we ended up with ptid.h/ptid.c, instead of inferior-common.h (or some such). If the resulting file is just a dumping ground of miscellaneous things, then call it that. Say, foo-misc.h or foo-defs.h, not foo-common.h.


OngoingWork LocalRemoteFeatureParity

None: Common (last edited 2016-01-16 14:43:53 by PedroAlves)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.