value of @code{myglobal} in the current inferior.
-Occasionaly, when debugging @value{GDBN} itself, it may be useful to
+Occasionally, when debugging @value{GDBN} itself, it may be useful to
get more info about the relationship of inferiors, programs, address
spaces in a debug session. You can do that with the @w{@code{maint
info program-spaces}} command.
results back to @value{GDBN}. Whatever the target reports back to
@value{GDBN}, @value{GDBN} will report back to the user. @value{GDBN}
assumes that the memory and registers that the target reports are in a
-consistant state, but @value{GDBN} accepts whatever it is given.
+consistent state, but @value{GDBN} accepts whatever it is given.
}.
On some platforms, @value{GDBN} has built-in support for reverse
disable the workarounds.
The argument @var{identifier} identifies the @sc{cpu} and is of the
-form: @code{@var{vendor}:@var{procesor identifier}}. In addition,
+form: @code{@var{vendor}:@var{processor identifier}}. In addition,
there are two special identifiers, @code{none} and @code{auto}
(default).
objfile /build/test frame-filters:
Priority Enabled Name
- 999 Yes BuildProgra Filter
+ 999 Yes BuildProgramFilter
(gdb) disable frame-filter /build/test BuildProgramFilter
(gdb) info frame-filter
recorded as @file{/project/build}, and the @dfn{source path} is
@file{/mnt/cross:$cdir:$cwd} while the current working directory of
the @value{GDBN} session is @file{/home/user}, then @value{GDBN} will
-search for the source file in the following loctions:
+search for the source file in the following locations:
@enumerate
@item info registers @var{reggroup} @dots{}
Print the name and value of the registers in each of the specified
-@var{reggroup}s. The @var{reggoup} can be any of those returned by
+@var{reggroup}s. The @var{reggroup} can be any of those returned by
@code{maint print reggroups} (@pxref{Maintenance Commands}).
@item info registers @var{regname} @dots{}
@value{GDBN} to hold the contents of the value. It is possible in
some languages with dynamic typing systems, that an invalid program
may indicate a value that is incorrectly large, this in turn may cause
-@value{GDBN} to try and allocate an overly large ammount of memory.
+@value{GDBN} to try and allocate an overly large amount of memory.
@table @code
@kindex set max-value-size
@value{CALLSEQ2B}, @value{GDBN} cannot find which one from the inferior state.
@code{initial:} state shows some random possible calling sequence @value{GDBN}
-has found. It then finds another possible calling sequcen - that one is
+has found. It then finds another possible calling sequence - that one is
prefixed by @code{compare:}. The non-ambiguous intersection of these two is
printed as the @code{reduced:} calling sequence. That one could have many
-futher @code{compare:} and @code{reduced:} statements as long as there remain
+further @code{compare:} and @code{reduced:} statements as long as there remain
any non-ambiguous sequence entries.
For the frame of function @code{b} in both cases there are different possible
@code{$pc} values (@code{0x4004cc} or @code{0x4004ce}), therefore this frame is
-also ambigous. The only non-ambiguous frame is the one for function @code{a},
+also ambiguous. The only non-ambiguous frame is the one for function @code{a},
therefore this one is displayed to the user while the ambiguous frames are
omitted.
@value{GDBN} cannot find out from the inferior state if and how many times did
function @code{a} call itself (via function @code{b}) as these calls would be
-tail calls. Such tail calls would modify thue @code{i} variable, therefore
+tail calls. Such tail calls would modify the @code{i} variable, therefore
@value{GDBN} cannot be sure the value it knows would be right - @value{GDBN}
prints @code{<optimized out>} instead.
$_sdata}. This collects arbitrary user data passed in the probe point
call to the tracing library. In the UST example above, you'll see
that the third argument to @code{trace_mark} is a printf-like format
-string. The user data is then the result of running that formating
+string. The user data is then the result of running that formatting
string against the following arguments. Note that @code{info
static-tracepoint-markers} command output lists that format string in
the @samp{Data:} field.
@kindex info task @var{taskno}
@item info task @var{taskno}
-This command shows detailled informations on the specified task, as in
+This command shows detailed informations on the specified task, as in
the following example:
@smallexample
@iftex
In addition, some systems may provide additional process information
in core files. Note that a core file may include a subset of the
information available from a live process. Process information is
-currently avaiable from cores created on @sc{gnu}/Linux and FreeBSD
+currently available from cores created on @sc{gnu}/Linux and FreeBSD
systems.
@table @code
Control the styling of titles. These are managed with the
@code{set style title} family of commands. By default, this style's
intensity is bold. Commands are using the title style to improve
-the readibility of large output. For example, the commands
+the readability of large output. For example, the commands
@command{apropos} and @command{help} are using the title style
for the command names.
Displays the current state of displaying @value{GDBN} target debugging
info.
@item set debug timestamp
-@cindex timestampping debugging info
+@cindex timestamping debugging info
Turns on or off display of timestamps with @value{GDBN} debugging info.
When enabled, seconds and microseconds are displayed before each debugging
message.
@kindex help user-defined
@item help user-defined
List all user-defined commands and all python commands defined in class
-COMAND_USER. The first line of the documentation or docstring is
+COMMAND_USER. The first line of the documentation or docstring is
included (if any).
@kindex show user
On some targets, @value{GDBN} is capable of processing MI commands
even while the target is running. This is called @dfn{asynchronous
command execution} (@pxref{Background Execution}). The frontend may
-specify a preferrence for asynchronous execution using the
+specify a preference for asynchronous execution using the
@code{-gdb-set mi-async 1} command, which should be emitted before
either running the executable or attaching to the target. After the
frontend has started the executable or attached to the target, it can
@node Thread groups
@subsection Thread groups
@value{GDBN} may be used to debug several processes at the same time.
-On some platfroms, @value{GDBN} may support debugging of several
+On some platforms, @value{GDBN} may support debugging of several
hardware systems, each one having several cores with several different
processes running on each core. This section describes the MI
mechanism to support such debugging scenarios.
exceptionally present if the breakpoint is enabled and has a single, disabled
location.
-The value is a list of locations. The format of a location is decribed below.
+The value is a list of locations. The format of a location is described below.
@end table
@item @code{-var-update}
@tab update the variable and its children
@item @code{-var-set-frozen}
-@tab set frozeness attribute
+@tab set frozenness attribute
@item @code{-var-set-update-range}
@tab set range of children to display on update
@end multitable
every address, which is not practical. Therefore, @value{GDBN} will
attempt to read all accessible memory units at either beginning or the end
of the region, using a binary division scheme. This heuristic works
-well for reading accross a memory map boundary. Note that if a region
+well for reading across a memory map boundary. Note that if a region
has a readable range that is neither at the beginning or the end,
@value{GDBN} will not read it.
@ftable @samp
@item frozen-varobjs
Indicates support for the @code{-var-set-frozen} command, as well
-as possible presense of the @code{frozen} field in the output
+as possible presence of the @code{frozen} field in the output
of @code{-varobj-create}.
@item pending-breakpoints
Indicates support for the @option{-f} option to the @code{-break-insert}
Broadly speaking, the JIT interface mirrors the dynamic loader interface. The
JIT compiler communicates with @value{GDBN} by writing data into a global
-variable and calling a fuction at a well-known symbol. When @value{GDBN}
+variable and calling a function at a well-known symbol. When @value{GDBN}
attaches, it reads a linked list of symbol files from the global variable to
find existing code, and puts a breakpoint in the function so that it can find
out about additional code.
@item --with-gdb-datadir=@var{path}
Set the @value{GDBN}-specific data directory. @value{GDBN} will look
here for certain supporting files or scripts. This defaults to the
-@file{gdb} subdirectory of @samp{datadi} (which can be set using
+@file{gdb} subdirectory of @samp{datadir} (which can be set using
@code{--datadir}).
@item --with-relocated-sources=@var{dir}
stopped.
@emph{Note:} In non-stop mode, a thread is considered running until
-@value{GDBN} acknowleges an asynchronous stop notification for it with
+@value{GDBN} acknowledges an asynchronous stop notification for it with
the @samp{vStopped} packet (@pxref{Remote Non-Stop}).
The stub must support @samp{vCont} if it reports support for
@command{gdbserver} handles unknown packets, it is important that this
packet be handled in the same way as other unknown @samp{v} packets.
If this packet is handled differently to other unknown @samp{v}
-packets then it is possile that @value{GDBN} may run into problems in
+packets then it is possible that @value{GDBN} may run into problems in
other areas, specifically around use of @samp{vFile:setfs:}.
@item vRun;@var{filename}@r{[};@var{argument}@r{]}@dots{}
@table @samp
@item OK
The stub has switched to no-acknowledgment mode.
-@value{GDBN} acknowledges this reponse,
+@value{GDBN} acknowledges this response,
but neither the stub nor @value{GDBN} shall send or expect further
@samp{+}/@samp{-} acknowledgments in the current connection.
@item @w{}
target features mechanism (@pxref{Target Descriptions}), but focuses
on a different aspect of target.
-Operating system information is retrived from the target via the
+Operating system information is retrieved from the target via the
remote protocol, using @samp{qXfer} requests (@pxref{qXfer osdata
read}). The object name in the request should be @samp{osdata}, and
the @var{annex} identifies the data to be fetched.
projects / binutils-gdb.git / commitdiff