Differences between revisions 2 and 3
Revision 2 as of 2011-05-16 04:55:20
Size: 1826
Editor: YaoQi
Comment:
Revision 3 as of 2011-05-16 05:27:22
Size: 3065
Editor: YaoQi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
  * 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.   * 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. As part of this piece of work, part of gdb_proc_serivce.h in GDB and GDBserver can be moved to common dir, and leave its own definition of 'struct ps_prochandle'.
  * Part of terminal.h is duplicated as well, and we can move them to common/ dir.

== Build/Configure ==

In order not to mess up the plan above, Yao moves build/configure related stuff into a separate section. In March 2011, Yao gave a try to build stuffs in common/ directory into libcommon.a, for GDB and GDBserver to link. See the thread on this [[http://sourceware.org/ml/gdb-patches/2011-02/msg00209.html|here]]. Finally, patches were dropped from CVS, because of various failures they caused.

So far, we have three possible approaches,
1. Don't have its own build stuff in common/, let gdb or gdbserver to build them.
2. Create Makefile.am and m4 files, but don't creat configure files. Similar to what we did for gnulib. This is suggested by Pedro.
3. Use Yao's original's patches, with various bugs fixed.

== Related things ==

  * Change gdbserver to use automake. Tom Tromey has a [[http://sourceware.org/ml/gdb-patches/2011-02/msg00493.html|patch]] to convert gdbserver to automake, so the dependence tracking can be done automatically.

Common part of GDB and GDBserver

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

1. Goal

The goal of this project is to reduce the code duplication between GDB and GDBserver, and to signify the stuffs in common directory.

2. Plan

Here is something like a plan on what we can do on this project,

  • 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 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.

  • 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 here.

  • 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
  • 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. As part of this piece of work, part of gdb_proc_serivce.h in GDB and GDBserver can be moved to common dir, and leave its own definition of 'struct ps_prochandle'.
  • Part of terminal.h is duplicated as well, and we can move them to common/ dir.

3. Build/Configure

In order not to mess up the plan above, Yao moves build/configure related stuff into a separate section. In March 2011, Yao gave a try to build stuffs in common/ directory into libcommon.a, for GDB and GDBserver to link. See the thread on this here. Finally, patches were dropped from CVS, because of various failures they caused.

So far, we have three possible approaches, 1. Don't have its own build stuff in common/, let gdb or gdbserver to build them. 2. Create Makefile.am and m4 files, but don't creat configure files. Similar to what we did for gnulib. This is suggested by Pedro. 3. Use Yao's original's patches, with various bugs fixed.

  • Change gdbserver to use automake. Tom Tromey has a patch to convert gdbserver to automake, so the dependence tracking can be done automatically.

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.