[RFC] Add patches from Chromium OS gdb

[RFC] Add patches from Chromium OS gdb

[Caroline Tice]

Hello,

I am working on maintaining gdb for the Chromium OS group.  This group
has a couple of small patches that they regularly apply to their local
gdb.  I am hoping to get these patches into mainline FSF gdb, to
reduce the amount of local patches we have to apply.  I have checked
out FSF gdb, applied the patches, built gdb, and tested it on
Linux/x86_64 with no regressions.

This patch combines two patches from the Chromium OS gdb.  The first
patch conditionally includes <wchar.h> in several readline files.

The second patch fixes some build problems in Gentoo linux
(http://bugs.gentoo.org/216369 and http://bugs.gentoo.org/299600)
.  The build would die because it was unable to find the opcodes/
directory.  The explanation from the gentoo bug website  is:

this is because gdb/Makefile contains no explicit -I path to the toplevel, and
--with-system-readline disables the implicit -I path

This patch updates some *tdep.c files to tell them explicitly where
the opcodes directory is.



Are these patches OK for FSF gdb?

-- Caroline Tice
cmtice@google.com


readline/ChangeLog.gdb

     * complete.c: Conditionally #include <wchar.h>
     * display.c: Likewise.
     * mbutil.c: Likewise.

gdb/ChangeLog

     * frv-tdep.c : Fix #include statement to look for opcodes/frv-desc.h
     in appropriate place.
     * lm32-tdep.c : Fix #include statement to look for opcodes/lm32-desc.h
     in appropriate place.
     * mep-tdep.c : Fix #include statements to look for opcodes/mep-desc.h
     and opcodes/mep-opc.h in appropriate place.

Index: gdb/frv-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/frv-tdep.c,v
retrieving revision 1.134
diff -c -p -r1.134 frv-tdep.c
*** gdb/frv-tdep.c    18 Mar 2011 18:52:30 -0000    1.134
--- gdb/frv-tdep.c    1 Aug 2011 16:46:37 -0000
***************
*** 32,38 ****
  #include "gdb_assert.h"
  #include "sim-regno.h"
  #include "gdb/sim-frv.h"
! #include "opcodes/frv-desc.h"    /* for the H_SPR_... enums */
  #include "symtab.h"
  #include "elf-bfd.h"
  #include "elf/frv.h"
--- 32,38 ----
  #include "gdb_assert.h"
  #include "sim-regno.h"
  #include "gdb/sim-frv.h"
! #include "../opcodes/frv-desc.h"    /* for the H_SPR_... enums */
  #include "symtab.h"
  #include "elf-bfd.h"
  #include "elf/frv.h"
Index: gdb/lm32-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/lm32-tdep.c,v
retrieving revision 1.8
diff -c -p -r1.8 lm32-tdep.c
*** gdb/lm32-tdep.c    18 Mar 2011 18:52:30 -0000    1.8
--- gdb/lm32-tdep.c    1 Aug 2011 16:46:37 -0000
***************
*** 35,41 ****
  #include "regcache.h"
  #include "trad-frame.h"
  #include "reggroups.h"
! #include "opcodes/lm32-desc.h"

  #include "gdb_string.h"

--- 35,41 ----
  #include "regcache.h"
  #include "trad-frame.h"
  #include "reggroups.h"
! #include "../opcodes/lm32-desc.h"

  #include "gdb_string.h"

Index: gdb/mep-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mep-tdep.c,v
retrieving revision 1.32
diff -c -p -r1.32 mep-tdep.c
*** gdb/mep-tdep.c    18 Mar 2011 18:52:31 -0000    1.32
--- gdb/mep-tdep.c    1 Aug 2011 16:46:38 -0000
***************
*** 53,60 ****

  /* Get the user's customized MeP coprocessor register names from
     libopcodes.  */
! #include "opcodes/mep-desc.h"
! #include "opcodes/mep-opc.h"

  ^L
  /* The gdbarch_tdep structure.  */
--- 53,60 ----

  /* Get the user's customized MeP coprocessor register names from
     libopcodes.  */
! #include "../opcodes/mep-desc.h"
! #include "../opcodes/mep-opc.h"

  ^L
  /* The gdbarch_tdep structure.  */
Index: readline/complete.c
===================================================================
RCS file: /cvs/src/src/readline/complete.c,v
retrieving revision 1.9
diff -c -p -r1.9 complete.c
*** readline/complete.c    11 May 2011 23:38:39 -0000    1.9
--- readline/complete.c    1 Aug 2011 16:46:42 -0000
***************
*** 25,30 ****
--- 25,35 ----
  #  include <config.h>
  #endif

+ #ifdef HAVE_WCHAR_H /* wcwidth() */
+ # define _GNU_SOURCE
+ # include <wchar.h>
+ #endif
+
  #include <sys/types.h>
  #include <fcntl.h>
  #if defined (HAVE_SYS_FILE_H)
Index: readline/display.c
===================================================================
RCS file: /cvs/src/src/readline/display.c,v
retrieving revision 1.13
diff -c -p -r1.13 display.c
*** readline/display.c    11 May 2011 23:38:39 -0000    1.13
--- readline/display.c    1 Aug 2011 16:46:43 -0000
***************
*** 25,30 ****
--- 25,35 ----
  #  include <config.h>
  #endif

+ #ifdef HAVE_WCHAR_H /* wcwidth() */
+ # define _GNU_SOURCE
+ # include <wchar.h>
+ #endif
+
  #include <sys/types.h>

  #if defined (HAVE_UNISTD_H)
Index: readline/mbutil.c
===================================================================
RCS file: /cvs/src/src/readline/mbutil.c,v
retrieving revision 1.7
diff -c -p -r1.7 mbutil.c
*** readline/mbutil.c    11 May 2011 23:38:39 -0000    1.7
--- readline/mbutil.c    1 Aug 2011 16:46:43 -0000
***************
*** 25,30 ****
--- 25,35 ----
  #  include <config.h>
  #endif

+ #ifdef HAVE_WCHAR_H /* wcwidth() */
+ # define _GNU_SOURCE
+ # include <wchar.h>
+ #endif
+
  #include <sys/types.h>
  #include <fcntl.h>
  #include "posixjmp.h"

Re: [RFC] Add patches from Chromium OS gdb

[Tom Tromey]

>>>>> "Caroline" == Caroline Tice <cmtice@google.com> writes:

Caroline> This patch combines two patches from the Chromium OS gdb.  The first
Caroline> patch conditionally includes <wchar.h> in several readline files.

I think readline fixes should be sent upstream first.  If the readline
maintainer agrees to them, then we can put them in our tree.

However, are they really needed?  In the current tree, the readline
source files include rlmbutil.h, which includes wchar.h.

Caroline> this is because gdb/Makefile contains no explicit -I path to
Caroline> the toplevel, and --with-system-readline disables the implicit
Caroline> -I path

I tried a build using --with-system-readline, and it worked fine for me.
So I think something else must be going on.

Tom