This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[patch] comment typos
- From: Michael Snyder <msnyder at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Sat, 10 Jul 2004 01:20:56 +0000
- Subject: [patch] comment typos
- Organization: Red Hat, Inc.
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);