This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] comment typos


Oh well... how many gdb patches can be explained in song?


You won't admit you love me And so How am I ever To know You only tell me Perhaps, perhaps, perhaps

A million times I ask you
And then
I ask you over
Again
You only answer
Perhaps, perhaps, perhaps

If you can't make your mind up
We'll never get started
And I don't wanna' wind up
Being parted, broken hearted

So if you really love me
Say yes
But if you don't, dear,
Confess
And please don't tell me
Perhaps, perhaps, perhaps


2004-07-10  Michael Snyder  <msnyder@redhat.com>

        * symfile.c (generic_load): Comment typo.
        * stack.c (get_selected_block): Ditto.
        * regcache.c (regcache_cooked_read): Ditto.
        * monitor.c (monitor_debug): Ditto.
        * mips-tdep.c (mips_read_pc): Ditto.
        * i386-linux-nat.c (ps_get_thread_area): Ditto.
        * gdb_mbuild.sh: Ditto.
        * gdbarch.sh: Ditto.
        * gdbarch.h: Ditto.

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.133
diff -p -r1.133 symfile.c
*** symfile.c	24 Jun 2004 22:09:34 -0000	1.133
--- symfile.c	10 Jul 2004 01:11:00 -0000
*************** generic_load (char *args, int from_tty)
*** 1532,1538 ****
       to a comment from remote-mips.c (where a call to symbol_file_add
       was commented out), making the call confuses GDB if more than one
       file is loaded in.  Some targets do (e.g., remote-vx.c) but
!      others don't (or didn't - perhaphs they have all been deleted).  */
  
    print_transfer_performance (gdb_stdout, cbdata.data_count,
  			      cbdata.write_count, end_time - start_time);
--- 1532,1538 ----
       to a comment from remote-mips.c (where a call to symbol_file_add
       was commented out), making the call confuses GDB if more than one
       file is loaded in.  Some targets do (e.g., remote-vx.c) but
!      others don't (or didn't - perhaps they have all been deleted).  */
  
    print_transfer_performance (gdb_stdout, cbdata.data_count,
  			      cbdata.write_count, end_time - start_time);
Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.109
diff -p -r1.109 stack.c
*** stack.c	20 Jun 2004 18:10:14 -0000	1.109
--- stack.c	10 Jul 2004 01:11:00 -0000
*************** get_selected_block (CORE_ADDR *addr_in_b
*** 1578,1584 ****
      return 0;
  
    /* NOTE: cagney/2002-11-28: Why go to all this effort to not create
!      a selected/current frame?  Perhaphs this function is called,
       indirectly, by WFI in "infrun.c" where avoiding the creation of
       an inner most frame is very important (it slows down single
       step).  I suspect, though that this was true in the deep dark
--- 1578,1584 ----
      return 0;
  
    /* NOTE: cagney/2002-11-28: Why go to all this effort to not create
!      a selected/current frame?  Perhaps this function is called,
       indirectly, by WFI in "infrun.c" where avoiding the creation of
       an inner most frame is very important (it slows down single
       step).  I suspect, though that this was true in the deep dark
Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.115
diff -p -r1.115 regcache.c
*** regcache.c	28 Jun 2004 23:59:28 -0000	1.115
--- regcache.c	10 Jul 2004 01:11:00 -0000
*************** regcache_cooked_read (struct regcache *r
*** 845,851 ****
    else if (regcache->readonly_p
  	   && regnum < regcache->descr->nr_cooked_registers
  	   && regcache->register_valid_p[regnum])
!     /* Read-only register cache, perhaphs the cooked value was cached?  */
      memcpy (buf, register_buffer (regcache, regnum),
  	    regcache->descr->sizeof_register[regnum]);
    else
--- 845,851 ----
    else if (regcache->readonly_p
  	   && regnum < regcache->descr->nr_cooked_registers
  	   && regcache->register_valid_p[regnum])
!     /* Read-only register cache, perhaps the cooked value was cached?  */
      memcpy (buf, register_buffer (regcache, regnum),
  	    regcache->descr->sizeof_register[regnum]);
    else
Index: monitor.c
===================================================================
RCS file: /cvs/src/src/gdb/monitor.c,v
retrieving revision 1.47
diff -p -r1.47 monitor.c
*** monitor.c	25 May 2004 14:58:28 -0000	1.47
--- monitor.c	10 Jul 2004 01:11:01 -0000
*************** static void monitor_debug (const char *f
*** 153,159 ****
  static int monitor_debug_p = 0;
  
  /* NOTE: This file alternates between monitor_debug_p and remote_debug
!    when determining if debug information is printed.  Perhaphs this
     could be simplified. */
  
  static void
--- 153,159 ----
  static int monitor_debug_p = 0;
  
  /* NOTE: This file alternates between monitor_debug_p and remote_debug
!    when determining if debug information is printed.  Perhaps this
     could be simplified. */
  
  static void
Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.300
diff -p -r1.300 mips-tdep.c
*** mips-tdep.c	22 Jun 2004 00:01:03 -0000	1.300
--- mips-tdep.c	10 Jul 2004 01:11:02 -0000
*************** pc_is_mips16 (bfd_vma memaddr)
*** 825,831 ****
      return 0;
  }
  
! /* MIPS believes that the PC has a sign extended value.  Perhaphs the
     all registers should be sign extended for simplicity? */
  
  static CORE_ADDR
--- 825,831 ----
      return 0;
  }
  
! /* MIPS believes that the PC has a sign extended value.  Perhaps the
     all registers should be sign extended for simplicity? */
  
  static CORE_ADDR
Index: i386-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-linux-nat.c,v
retrieving revision 1.55
diff -p -r1.55 i386-linux-nat.c
*** i386-linux-nat.c	9 Apr 2004 16:31:01 -0000	1.55
--- i386-linux-nat.c	10 Jul 2004 01:11:02 -0000
*************** ps_get_thread_area (const struct ps_proc
*** 738,744 ****
  
       Is this function needed?  I'm guessing that the `base' is the
       address of a a descriptor that libthread_db uses to find the
!      thread local address base that GDB needs.  Perhaphs that
       descriptor is defined by the ABI.  Anyway, given that
       libthread_db calls this function without prompting (gdb
       requesting tls base) I guess it needs info in there anyway.  */
--- 738,744 ----
  
       Is this function needed?  I'm guessing that the `base' is the
       address of a a descriptor that libthread_db uses to find the
!      thread local address base that GDB needs.  Perhaps that
       descriptor is defined by the ABI.  Anyway, given that
       libthread_db calls this function without prompting (gdb
       requesting tls base) I guess it needs info in there anyway.  */
Index: gdb_mbuild.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdb_mbuild.sh,v
retrieving revision 1.7
diff -p -r1.7 gdb_mbuild.sh
*** gdb_mbuild.sh	8 Feb 2003 00:39:53 -0000	1.7
--- gdb_mbuild.sh	10 Jul 2004 01:11:02 -0000
*************** do
*** 205,211 ****
      trap "exit 1"  1 2 15
      dir=${builddir}/${target}
  
!     # Should a scratch rebuild be forced, for perhaphs the entire
      # build be skipped?
  
      if ${force}
--- 205,211 ----
      trap "exit 1"  1 2 15
      dir=${builddir}/${target}
  
!     # Should a scratch rebuild be forced, for perhaps the entire
      # build be skipped?
  
      if ${force}
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.335
diff -p -r1.335 gdbarch.sh
*** gdbarch.sh	22 Jun 2004 17:47:59 -0000	1.335
--- gdbarch.sh	10 Jul 2004 01:11:02 -0000
*************** f:=:CORE_ADDR:smash_text_address:CORE_AD
*** 667,673 ****
  # single step.  If not, then implement single step using breakpoints.
  F:=:void:software_single_step:enum target_signal sig, int insert_breakpoints_p:sig, insert_breakpoints_p
  # FIXME: cagney/2003-08-28: Need to find a better way of selecting the
! # disassembler.  Perhaphs objdump can handle it?
  f:TARGET_PRINT_INSN:int:print_insn:bfd_vma vma, struct disassemble_info *info:vma, info:::0:
  f:=:CORE_ADDR:skip_trampoline_code:CORE_ADDR pc:pc:::generic_skip_trampoline_code::0
  
--- 667,673 ----
  # single step.  If not, then implement single step using breakpoints.
  F:=:void:software_single_step:enum target_signal sig, int insert_breakpoints_p:sig, insert_breakpoints_p
  # FIXME: cagney/2003-08-28: Need to find a better way of selecting the
! # disassembler.  Perhaps objdump can handle it?
  f:TARGET_PRINT_INSN:int:print_insn:bfd_vma vma, struct disassemble_info *info:vma, info:::0:
  f:=:CORE_ADDR:skip_trampoline_code:CORE_ADDR pc:pc:::generic_skip_trampoline_code::0
  
Index: gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.263
diff -p -r1.263 gdbarch.h
*** gdbarch.h	20 Jun 2004 18:10:13 -0000	1.263
--- gdbarch.h	10 Jul 2004 01:11:03 -0000
*************** extern void set_gdbarch_software_single_
*** 1749,1755 ****
  #endif
  
  /* FIXME: cagney/2003-08-28: Need to find a better way of selecting the
!    disassembler.  Perhaphs objdump can handle it? */
  
  typedef int (gdbarch_print_insn_ftype) (bfd_vma vma, struct disassemble_info *info);
  extern int gdbarch_print_insn (struct gdbarch *gdbarch, bfd_vma vma, struct disassemble_info *info);
--- 1749,1755 ----
  #endif
  
  /* FIXME: cagney/2003-08-28: Need to find a better way of selecting the
!    disassembler.  Perhaps objdump can handle it? */
  
  typedef int (gdbarch_print_insn_ftype) (bfd_vma vma, struct disassemble_info *info);
  extern int gdbarch_print_insn (struct gdbarch *gdbarch, bfd_vma vma, struct disassemble_info *info);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]