* gdb.texinfo (Target Commands, Bug Reporting, File Options)
(Symbols): Fix usage of "e.g.". * gdbint.texinfo (libgdb, Symbol Handling, Native Debugging) (Coding): Fix usage of "e.g.".
This commit is contained in:
Eli Zaretskii
parent
49236396bb
commit
c1468174e7
|
|
@ -1,3 +1,11 @@
|
|||
2005-12-24 Eli Zaretskii <eliz@gnu.org>
|
||||
|
||||
* gdb.texinfo (Target Commands, Bug Reporting, File Options)
|
||||
(Symbols): Fix usage of "e.g.".
|
||||
|
||||
* gdbint.texinfo (libgdb, Symbol Handling, Native Debugging)
|
||||
(Coding): Fix usage of "e.g.".
|
||||
|
||||
2005-12-23 Eli Zaretskii <eliz@gnu.org>
|
||||
|
||||
* stabs.texinfo:
|
||||
|
|
|
|||
|
|
@ -875,7 +875,7 @@ If the second argument begins with a decimal digit, @value{GDBN} will
|
|||
first attempt to attach to it as a process, and if that fails, attempt
|
||||
to open it as a corefile. If you have a corefile whose name begins with
|
||||
a digit, you can prevent @value{GDBN} from treating it as a pid by
|
||||
prefixing it with @file{./}, eg. @file{./12345}.
|
||||
prefixing it with @file{./}, e.g.@: @file{./12345}.
|
||||
|
||||
If @value{GDBN} has not been configured to included core file support,
|
||||
such as for most embedded targets, then it will complain about a second
|
||||
|
|
@ -10239,7 +10239,7 @@ whose names contain a match for regular expression @var{regexp}.
|
|||
Thus, @samp{info fun step} finds all functions whose names
|
||||
include @code{step}; @samp{info fun ^step} finds those whose names
|
||||
start with @code{step}. If a function name contains characters
|
||||
that conflict with the regular expression language (eg.
|
||||
that conflict with the regular expression language (e.g.@:
|
||||
@samp{operator*()}), they may be quoted with a backslash.
|
||||
|
||||
@kindex info variables
|
||||
|
|
@ -11640,7 +11640,7 @@ A core dump file. @samp{target core @var{filename}} is the same as
|
|||
@item target remote @var{dev}
|
||||
@cindex remote target
|
||||
Remote serial target in GDB-specific protocol. The argument @var{dev}
|
||||
specifies what serial device to use for the connection (e.g.
|
||||
specifies what serial device to use for the connection (e.g.@:
|
||||
@file{/dev/ttya}). @xref{Remote, ,Remote debugging}. @code{target remote}
|
||||
supports the @code{load} command. This is only useful if you have
|
||||
some other way of getting the stub to the target system, and you can put
|
||||
|
|
@ -15916,7 +15916,7 @@ end
|
|||
|
||||
You can define a hook for any single-word command in @value{GDBN}, but
|
||||
not for command aliases; you should define a hook for the basic command
|
||||
name, e.g. @code{backtrace} rather than @code{bt}.
|
||||
name, e.g.@: @code{backtrace} rather than @code{bt}.
|
||||
@c FIXME! So how does Joe User discover whether a command is an alias
|
||||
@c or not?
|
||||
If an error occurs during the execution of your hook, execution of
|
||||
|
|
@ -21220,12 +21220,12 @@ The type of machine you are using, and the operating system name and
|
|||
version number.
|
||||
|
||||
@item
|
||||
What compiler (and its version) was used to compile @value{GDBN}---e.g.
|
||||
What compiler (and its version) was used to compile @value{GDBN}---e.g.@:
|
||||
``@value{GCC}--2.8.1''.
|
||||
|
||||
@item
|
||||
What compiler (and its version) was used to compile the program you are
|
||||
debugging---e.g. ``@value{GCC}--2.8.1'', or ``HP92453-01 A.10.32.03 HP
|
||||
debugging---e.g.@: ``@value{GCC}--2.8.1'', or ``HP92453-01 A.10.32.03 HP
|
||||
C Compiler''. For GCC, you can say @code{gcc --version} to get this
|
||||
information; for other compilers, see the documentation for those
|
||||
compilers.
|
||||
|
|
|
|||
|
|
@ -1458,7 +1458,7 @@ As a client querying @code{libgdb} (using the @file{ui-out} builder) to
|
|||
obtain various status values from @value{GDBN}.
|
||||
@end itemize
|
||||
|
||||
Since @code{libgdb} could have multiple clients (e.g. a GUI supporting
|
||||
Since @code{libgdb} could have multiple clients (e.g., a GUI supporting
|
||||
the existing @value{GDBN} CLI), those clients must co-operate when
|
||||
controlling @code{libgdb}. In particular, a client must ensure that
|
||||
@code{libgdb} is idle (i.e. no other client is using @code{libgdb})
|
||||
|
|
@ -1606,7 +1606,7 @@ symbol-file into a set of psymtabs or symtabs.
|
|||
@code{@var{xyz}_sym_init} for possible initialization. @code{addr} is
|
||||
the offset between the file's specified start address and its true
|
||||
address in memory. @code{mainline} is 1 if this is the main symbol
|
||||
table being read, and 0 if a secondary symbol file (e.g. shared library
|
||||
table being read, and 0 if a secondary symbol file (e.g., shared library
|
||||
or dynamically loaded file) is being read.@refill
|
||||
@end table
|
||||
|
||||
|
|
@ -1680,7 +1680,7 @@ code in the debugger) to reference a symbol:
|
|||
@findex find_pc_function
|
||||
@findex find_pc_line
|
||||
@item
|
||||
By its address (e.g. execution stops at some address which is inside a
|
||||
By its address (e.g., execution stops at some address which is inside a
|
||||
function in this file). The address will be noticed to be in the
|
||||
range of this psymtab, and the full symtab will be read in.
|
||||
@code{find_pc_function}, @code{find_pc_line}, and other
|
||||
|
|
@ -1689,7 +1689,7 @@ range of this psymtab, and the full symtab will be read in.
|
|||
@cindex lookup_symbol
|
||||
@item
|
||||
By its name
|
||||
(e.g. the user asks to print a variable, or set a breakpoint on a
|
||||
(e.g., the user asks to print a variable, or set a breakpoint on a
|
||||
function). Global names and file-scope names will be found in the
|
||||
psymtab, which will cause the symtab to be pulled in. Local names will
|
||||
have to be qualified by a global name, or a file-scope name, in which
|
||||
|
|
@ -4322,12 +4322,12 @@ code for parsing your OS's core files, or customize
|
|||
machine uses to define the struct of registers that is accessible
|
||||
(possibly in the u-area) in a core file (rather than
|
||||
@file{machine/reg.h}), and an include file that defines whatever header
|
||||
exists on a core file (e.g. the u-area or a @code{struct core}). Then
|
||||
exists on a core file (e.g., the u-area or a @code{struct core}). Then
|
||||
modify @code{trad_unix_core_file_p} to use these values to set up the
|
||||
section information for the data segment, stack segment, any other
|
||||
segments in the core file (perhaps shared library contents or control
|
||||
information), ``registers'' segment, and if there are two discontiguous
|
||||
sets of registers (e.g. integer and float), the ``reg2'' segment. This
|
||||
sets of registers (e.g., integer and float), the ``reg2'' segment. This
|
||||
section information basically delimits areas in the core file in a
|
||||
standard way, which the section-reading routines in BFD know how to seek
|
||||
around in.
|
||||
|
|
@ -4728,7 +4728,7 @@ discard_cleanups (old);
|
|||
return file;
|
||||
@end smallexample
|
||||
|
||||
Some functions, e.g. @code{fputs_filtered()} or @code{error()}, specify
|
||||
Some functions, e.g., @code{fputs_filtered()} or @code{error()}, specify
|
||||
that they ``should not be called when cleanups are not in place''. This
|
||||
means that any actions you need to reverse in the case of an error or
|
||||
interruption must be on the cleanup chain before you call these
|
||||
|
|
|
|||
Loading…
Reference in New Issue