freedom to copy and modify this GNU Manual, like GNU software. Copies
published by the Free Software Foundation raise funds for GNU
development.''
+@page
+This edition of the GDB manual is dedicated to the memory of Fred
+Fish. Fred was a long-standing contributor to GDB and to Free
+software in general. We will miss him.
@end titlepage
@page
Copyright (C) 1988-2006 Free Software Foundation, Inc.
+This edition of the GDB manual is dedicated to the memory of Fred
+Fish. Fred was a long-standing contributor to GDB and to Free
+software in general. We will miss him.
+
@menu
* Summary:: Summary of @value{GDBN}
* Sample Session:: A sample @value{GDBN} session
executing the command.
@end table
-If you exit @value{GDBN} or use the @code{run} command while you have an
-attached process, you kill that process. By default, @value{GDBN} asks
-for confirmation if you try to do either of these things; you can
-control whether or not you need to confirm by using the @code{set
-confirm} command (@pxref{Messages/Warnings, ,Optional Warnings and
+If you exit @value{GDBN} while you have an attached process, you detach
+that process. If you use the @code{run} command, you kill that process.
+By default, @value{GDBN} asks for confirmation if you try to do either of these
+things; you can control whether or not you need to confirm by using the
+@code{set confirm} command (@pxref{Messages/Warnings, ,Optional Warnings and
Messages}).
@node Kill Process
Even though the unit size @var{u} is ignored for the formats @samp{s}
and @samp{i}, you might still want to use a count @var{n}; for example,
@samp{3i} specifies that you want to see three machine instructions,
-including any operands. The command @code{disassemble} gives an
-alternative way of inspecting machine instructions; see @ref{Machine
-Code,,Source and Machine Code}.
+including any operands. For convenience, especially when used with
+the @code{display} command, the @samp{i} format also prints branch delay
+slot instructions, if any, beyond the count specified, which immediately
+follow the last instruction that is within the count. The command
+@code{disassemble} gives an alternative way of inspecting machine
+instructions; see @ref{Machine Code,,Source and Machine Code}.
All the defaults for the arguments to @code{x} are designed to make it
easy to continue scanning memory with minimal specifications each time
@cindex @file{.debug} subdirectories
@cindex debugging information directory, global
@cindex global debugging information directory
+@cindex build ID, and separate debugging files
+@cindex @file{.build-id} directory
@value{GDBN} allows you to put a program's debugging information in a
file separate from the executable itself, in a way that allows
@value{GDBN} to find and load the debugging information automatically.
-Since debugging information can be very large --- sometimes larger
-than the executable code itself --- some systems distribute debugging
+Since debugging information can be very large---sometimes larger
+than the executable code itself---some systems distribute debugging
information for their executables in separate files, which users can
install only when they need to debug a problem.
-If an executable's debugging information has been extracted to a
-separate file, the executable should contain a @dfn{debug link} giving
-the name of the debugging information file (with no directory
-components), and a checksum of its contents. (The exact form of a
-debug link is described below.) If the full name of the directory
-containing the executable is @var{execdir}, and the executable has a
-debug link that specifies the name @var{debugfile}, then @value{GDBN}
-will automatically search for the debugging information file in three
-places:
+@value{GDBN} supports two ways of specifying the separate debug info
+file:
@itemize @bullet
@item
-the directory containing the executable file (that is, it will look
-for a file named @file{@var{execdir}/@var{debugfile}},
+The executable contains a @dfn{debug link} that specifies the name of
+the separate debug info file. The separate debug file's name is
+usually @file{@var{executable}.debug}, where @var{executable} is the
+name of the corresponding executable file without leading directories
+(e.g., @file{ls.debug} for @file{/usr/bin/ls}). In addition, the
+debug link specifies a CRC32 checksum for the debug file, which
+@value{GDBN} uses to validate that the executable and the debug file
+came from the same build.
+
+@item
+The executable contains a @dfn{build ID}, a unique signature that is
+also present in the corresponding debug info file. (This is supported
+only on some operating systems, notably on @sc{gnu}/Linux. For more
+details about this feature, see
+@uref{http://fedoraproject.org/wiki/Releases/FeatureBuildId, the
+Fedora Project's description of the buid ID feature}.) The debug info
+file's name is not specified explicitly by the debug ID, but can be
+computed from the build ID, see below.
+@end itemize
+
+Depending on the way the debug info file is specified, @value{GDBN}
+uses two different methods of looking for the debug file:
+
+@itemize @bullet
@item
-a subdirectory of that directory named @file{.debug} (that is, the
-file @file{@var{execdir}/.debug/@var{debugfile}}, and
+For the ``debug link'' method, @value{GDBN} looks up the named file in
+the directory of the executable file, then in a subdirectory of that
+directory named @file{.debug}, and finally under the global debug
+directory, in a subdirectory whose name is identical to the leading
+directories of the executable's absolute file name.
+
@item
-a subdirectory of the global debug file directory that includes the
-executable's full path, and the name from the link (that is, the file
-@file{@var{globaldebugdir}/@var{execdir}/@var{debugfile}}, where
-@var{globaldebugdir} is the global debug file directory, and
-@var{execdir} has been turned into a relative path).
+For the ``debug ID'' method, @value{GDBN} looks in the
+@file{.build-id} subdirectory of the global debug directory for a file
+named @file{@var{nn}/@var{nnnnnnnn}.debug}, where @var{nn} are the
+first 2 hex characters of the debug ID signature, and @var{nnnnnnnn}
+are the rest of the signature. (Real signatures are 32 or more
+characters, not 10.)
@end itemize
-@noindent
-@value{GDBN} checks under each of these names for a debugging
-information file whose checksum matches that given in the link, and
-reads the debugging information from the first one it finds.
-
-So, for example, if you ask @value{GDBN} to debug @file{/usr/bin/ls},
-which has a link containing the name @file{ls.debug}, and the global
-debug directory is @file{/usr/lib/debug}, then @value{GDBN} will look
-for debug information in @file{/usr/bin/ls.debug},
-@file{/usr/bin/.debug/ls.debug}, and
+
+So, for example, suppose you ask @value{GDBN} to debug
+@file{/usr/bin/ls}, which has a @dfn{debug link} that specifies the
+file @file{ls.debug}, and a @dfn{build id} whose value in hex is
+@code{abcdef1234}. If the global debug directory is
+@file{/usr/lib/debug}, then @value{GDBN} will look for the following
+debug information files, in the indicated order:
+
+@itemize @minus
+@item
+@file{/usr/lib/debug/.build-id/ab/cdef1234.debug}
+@item
+@file{/usr/bin/ls.debug}
+@item
+@file{/usr/bin/.debug/ls.debug}
+@item
@file{/usr/lib/debug/usr/bin/ls.debug}.
+@end itemize
You can set the global debugging info directory's name, and view the
name @value{GDBN} is currently using.
@end table
@cindex @code{.gnu_debuglink} sections
-@cindex debug links
+@cindex debug link sections
A debug link is a special section of the executable file named
@code{.gnu_debuglink}. The section must contain:
contain a section named @code{.gnu_debuglink} with the contents
described above.
+@cindex @code{.note.gnu.build-id} sections
+@cindex build ID sections
+A build ID is a special section of the executable file named
+@code{.note.gnu.build-id}. This section contains unique
+identification for the built files---it remains the same across
+multiple builds of the same build tree. The default algorithm SHA1
+produces 160 bits (40 hexadecimal characters) of the content. The
+same section with an identical value is present in the original built
+binary with symbols, in its stripped variant, and in the separate
+debugging information file.
+
The debugging information file itself should be an ordinary
executable, containing a full set of linker symbols, sections, and
debugging information. The sections of the debugging information file
-should have the same names, addresses and sizes as the original file,
-but they need not contain any data --- much like a @code{.bss} section
+should have the same names, addresses, and sizes as the original file,
+but they need not contain any data---much like a @code{.bss} section
in an ordinary executable.
-As of December 2002, there is no standard GNU utility to produce
-separated executable / debugging information file pairs. Ulrich
-Drepper's @file{elfutils} package, starting with version 0.53,
-contains a version of the @code{strip} command such that the command
-@kbd{strip foo -f foo.debug} removes the debugging information from
-the executable file @file{foo}, places it in the file
-@file{foo.debug}, and leaves behind a debug link in @file{foo}.
+@sc{gnu} binary utilities (Binutils) package includes the
+@samp{objcopy} utility that can produce
+the separated executable / debugging information file pairs using the
+following commands:
+
+@smallexample
+@kbd{objcopy --only-keep-debug foo foo.debug}
+@kbd{strip -g foo}
+@kbd{objcopy --add-gnu-debuglink="foo.debug" "foo"}
+@end smallexample
-Since there are many different ways to compute CRC's (different
-polynomials, reversals, byte ordering, etc.), the simplest way to
-describe the CRC used in @code{.gnu_debuglink} sections is to give the
-complete code for a function that computes it:
+@noindent
+These commands remove the debugging
+information from the executable file @file{foo}, place it in the file
+@file{foo.debug}, and leave behind a debug link in @file{foo}. Ulrich
+Drepper's @file{elfutils} package, starting with version 0.53, contains
+a version of the @code{strip} command such that the command @kbd{strip foo -f
+foo.debug} has the same functionality as the three commands above.
+
+Since there are many different ways to compute CRC's for the debug
+link (different polynomials, reversals, byte ordering, etc.), the
+simplest way to describe the CRC used in @code{.gnu_debuglink}
+sections is to give the complete code for a function that computes it:
@kindex gnu_debuglink_crc32
@smallexample
@}
@end smallexample
+@noindent
+This computation does not apply to the ``build ID'' method.
+
@node Symbol Errors
@section Errors Reading Symbol Files
in @value{GDBN}. You may want to report the problem to the
@value{GDBN} developers.
-The available settings are:
+For each packet @var{name}, the command to enable or disable the
+packet is @code{set remote @var{name}-packet}. The available settings
+are:
-@multitable @columnfractions 0.3 0.2 0.35
+@multitable @columnfractions 0.28 0.32 0.25
@item Command Name
@tab Remote Packet
@tab Related Features
-@item @code{fetch-register-packet}
+@item @code{fetch-register}
@tab @code{p}
@tab @code{info registers}
-@item @code{set-register-packet}
+@item @code{set-register}
@tab @code{P}
@tab @code{set}
-@item @code{binary-download-packet}
+@item @code{binary-download}
@tab @code{X}
@tab @code{load}, @code{set}
-@item @code{read-aux-vector-packet}
+@item @code{read-aux-vector}
@tab @code{qXfer:auxv:read}
@tab @code{info auxv}
-@item @code{symbol-lookup-packet}
+@item @code{symbol-lookup}
@tab @code{qSymbol}
@tab Detecting multiple threads
-@item @code{verbose-resume-packet}
+@item @code{verbose-resume}
@tab @code{vCont}
@tab Stepping or resuming multiple threads
-@item @code{software-breakpoint-packet}
+@item @code{software-breakpoint}
@tab @code{Z0}
@tab @code{break}
-@item @code{hardware-breakpoint-packet}
+@item @code{hardware-breakpoint}
@tab @code{Z1}
@tab @code{hbreak}
-@item @code{write-watchpoint-packet}
+@item @code{write-watchpoint}
@tab @code{Z2}
@tab @code{watch}
-@item @code{read-watchpoint-packet}
+@item @code{read-watchpoint}
@tab @code{Z3}
@tab @code{rwatch}
-@item @code{access-watchpoint-packet}
+@item @code{access-watchpoint}
@tab @code{Z4}
@tab @code{awatch}
-@item @code{get-thread-local-storage-address-packet}
+@item @code{target-features}
+@tab @code{qXfer:features:read}
+@tab @code{set architecture}
+
+@item @code{library-info}
+@tab @code{qXfer:libraries:read}
+@tab @code{info sharedlibrary}
+
+@item @code{memory-map}
+@tab @code{qXfer:memory-map:read}
+@tab @code{info mem}
+
+@item @code{read-spu-object}
+@tab @code{qXfer:spu:read}
+@tab @code{info spu}
+
+@item @code{write-spu-object}
+@tab @code{qXfer:spu:write}
+@tab @code{info spu}
+
+@item @code{get-thread-local-@*storage-address}
@tab @code{qGetTLSAddr}
@tab Displaying @code{__thread} variables
@tab @code{qSupported}
@tab Remote communications parameters
-@item @code{pass-signals-packet}
+@item @code{pass-signals}
@tab @code{QPassSignals}
@tab @code{handle @var{signal}}
Interactively}, for the detailed description of the History library.
To issue a command to @value{GDBN} without affecting certain aspects of
-the state which is seen by users, prefix it with @samp{server }. This
+the state which is seen by users, prefix it with @samp{server }
+(@pxref{Server Prefix}). This
means that this command will not affect the command history, nor will it
affect @value{GDBN}'s notion of which command to repeat if @key{RET} is
pressed on a line by itself.
@item @code{-var-info-type}
@tab show the type of this variable object
@item @code{-var-info-expression}
-@tab print what this variable object represents
+@tab print parent-relative expression that this variable object represents
+@item @code{-var-info-path-expression}
+@tab print full expression that this variable object represents
@item @code{-var-show-attributes}
@tab is this variable editable? does it exist here?
@item @code{-var-evaluate-expression}
-var-info-expression @var{name}
@end smallexample
-Returns what is represented by the variable object @var{name}:
+Returns a string that is suitable for presenting this
+variable object in user interface. The string is generally
+not valid expression in the current language, and cannot be evaluated.
+
+For example, if @code{a} is an array, and variable object
+@code{A} was created for @code{a}, then we'll get this output:
@smallexample
- lang=@var{lang-spec},exp=@var{expression}
+(gdb) -var-info-expression A.1
+^done,lang="C",exp="1"
@end smallexample
@noindent
-where @var{lang-spec} is @code{@{"C" | "C++" | "Java"@}}.
+Here, the values of @code{lang} can be @code{@{"C" | "C++" | "Java"@}}.
+
+Note that the output of the @code{-var-list-children} command also
+includes those expressions, so the @code{-var-info-expression} command
+is of limited use.
+
+@subheading The @code{-var-info-path-expression} Command
+@findex -var-info-path-expression
+
+@subsubheading Synopsis
+
+@smallexample
+ -var-info-path-expression @var{name}
+@end smallexample
+
+Returns an expression that can be evaluated in the current
+context and will yield the same value that a variable object has.
+Compare this with the @code{-var-info-expression} command, which
+result can be used only for UI presentation. Typical use of
+the @code{-var-info-path-expression} command is creating a
+watchpoint from a variable object.
+
+For example, suppose @code{C} is a C@t{++} class, derived from class
+@code{Base}, and that the @code{Base} class has a member called
+@code{m_size}. Assume a variable @code{c} is has the type of
+@code{C} and a variable object @code{C} was created for variable
+@code{c}. Then, we'll get this output:
+@smallexample
+(gdb) -var-info-path-expression C.Base.public.m_size
+^done,path_expr=((Base)c).m_size)
+@end smallexample
@subheading The @code{-var-show-attributes} Command
@findex -var-show-attributes
@menu
* Annotations Overview:: What annotations are; the general syntax.
+* Server Prefix:: Issuing a command without affecting user state.
* Prompting:: Annotations marking @value{GDBN}'s need for input.
* Errors:: Annotations for error messages.
* Invalidation:: Some annotations describe things now invalid.
denotes a @samp{control-z} character) are annotations; the rest is
output from @value{GDBN}.
+@node Server Prefix
+@section The Server Prefix
+@cindex server prefix
+
+If you prefix a command with @samp{server } then it will not affect
+the command history, nor will it affect @value{GDBN}'s notion of which
+command to repeat if @key{RET} is pressed on a line by itself. This
+means that commands can be run behind a user's back by a front-end in
+a transparent manner.
+
+The server prefix does not affect the recording of values into the value
+history; to print a value without recording it into the value history,
+use the @code{output} command instead of the @code{print} command.
+
@node Prompting
@section Annotation for @value{GDBN} Input
* Interrupts::
* Examples::
* File-I/O Remote Protocol Extension::
+* Library List Format::
* Memory Map Format::
@end menu
Each byte of register data is described by two hex digits. The bytes
with the register are transmitted in target byte order. The size of
each register and their position within the @samp{g} packet are
-determined by the @value{GDBN} internal macros
-@code{DEPRECATED_REGISTER_RAW_SIZE} and @code{REGISTER_NAME} macros. The
+determined by the @value{GDBN} internal gdbarch functions
+@code{DEPRECATED_REGISTER_RAW_SIZE} and @code{gdbarch_register_name}. The
specification of several standard @samp{g} packets is specified below.
@item E @var{NN}
for an error.
and other information directly in the stop reply packet, reducing
round-trip latency. Single-step and breakpoint traps are reported
this way. Each @samp{@var{n}:@var{r}} pair is interpreted as follows:
-@enumerate
+
+@itemize @bullet
@item
If @var{n} is a hexadecimal number, it is a register number, and the
corresponding @var{r} gives that register's value. @var{r} is a
series of bytes in target byte order, with each byte given by a
two-digit hex number.
+
@item
If @var{n} is @samp{thread}, then @var{r} is the thread process ID, in
hex.
+
@item
-If @var{n} is @samp{watch}, @samp{rwatch}, or @samp{awatch}, then the
-packet indicates a watchpoint hit, and @var{r} is the data address, in
-hex.
+If @var{n} is a recognized @dfn{stop reason}, it describes a more
+specific event that stopped the target. The currently defined stop
+reasons are listed below. @var{aa} should be @samp{05}, the trap
+signal. At most one stop reason should be present.
+
@item
Otherwise, @value{GDBN} should ignore this @samp{@var{n}:@var{r}} pair
and go on to the next; this allows us to extend the protocol in the
future.
-@end enumerate
+@end itemize
+
+The currently defined stop reasons are:
+
+@table @samp
+@item watch
+@itemx rwatch
+@itemx awatch
+The packet indicates a watchpoint hit, and @var{r} is the data address, in
+hex.
+
+@cindex shared library events, remote reply
+@item library
+The packet indicates that the loaded libraries have changed.
+@value{GDBN} should use @samp{qXfer:libraries:read} to fetch a new
+list of loaded libraries. @var{r} is ignored.
+@end table
@item W @var{AA}
The process exited, and @var{AA} is the exit status. This is only
@item qOffsets
@cindex section offsets, remote request
@cindex @samp{qOffsets} packet
-Get section offsets that the target used when re-locating the downloaded
-image. @emph{Note: while a @code{Bss} offset is included in the
-response, @value{GDBN} ignores this and instead applies the @code{Data}
-offset to the @code{Bss} section.}
+Get section offsets that the target used when relocating the downloaded
+image.
Reply:
@table @samp
-@item Text=@var{xxx};Data=@var{yyy};Bss=@var{zzz}
+@item Text=@var{xxx};Data=@var{yyy}@r{[};Bss=@var{zzz}@r{]}
+Relocate the @code{Text} section by @var{xxx} from its original address.
+Relocate the @code{Data} section by @var{yyy} from its original address.
+If the object file format provides segment information (e.g.@: @sc{elf}
+@samp{PT_LOAD} program headers), @value{GDBN} will relocate entire
+segments by the supplied offsets.
+
+@emph{Note: while a @code{Bss} offset may be included in the response,
+@value{GDBN} ignores this and instead applies the @code{Data} offset
+to the @code{Bss} section.}
+
+@item TextSeg=@var{xxx}@r{[};DataSeg=@var{yyy}@r{]}
+Relocate the first segment of the object file, which conventionally
+contains program code, to a starting address of @var{xxx}. If
+@samp{DataSeg} is specified, relocate the second segment, which
+conventionally contains modifiable data, to a starting address of
+@var{yyy}. @value{GDBN} will report an error if the object file
+does not contain segment information, or does not contain at least
+as many segments as mentioned in the reply. Extra segments are
+kept at fixed offsets relative to the last relocated segment.
@end table
@item qP @var{mode} @var{threadid}
These are the currently defined stub features and their properties:
-@multitable @columnfractions 0.25 0.2 0.2 0.2
+@multitable @columnfractions 0.35 0.2 0.12 0.2
@c NOTE: The first row should be @headitem, but we do not yet require
@c a new enough version of Texinfo (4.7) to use @headitem.
@item Feature Name
@tab @samp{-}
@tab Yes
+@item @samp{qXfer:libraries:read}
+@tab No
+@tab @samp{-}
+@tab Yes
+
@item @samp{qXfer:memory-map:read}
@tab No
@tab @samp{-}
The remote stub understands the @samp{qXfer:features:read} packet
(@pxref{qXfer target description read}).
+@item qXfer:libraries:read
+The remote stub understands the @samp{qXfer:libraries:read} packet
+(@pxref{qXfer library list read}).
+
@item qXfer:memory-map:read
The remote stub understands the @samp{qXfer:memory-map:read} packet
(@pxref{qXfer memory map read}).
This packet is not probed by default; the remote stub must request it,
by supplying an appropriate @samp{qSupported} response (@pxref{qSupported}).
+@item qXfer:libraries:read:@var{annex}:@var{offset},@var{length}
+@anchor{qXfer library list read}
+Access the target's list of loaded libraries. @xref{Library List Format}.
+The annex part of the generic @samp{qXfer} packet must be empty
+(@pxref{qXfer read}).
+
+Targets which maintain a list of libraries in the program's memory do
+not need to implement this packet; it is designed for platforms where
+the operating system manages the list of loaded libraries.
+
+This packet is not probed by default; the remote stub must request it,
+by supplying an appropriate @samp{qSupported} response (@pxref{qSupported}).
+
@item qXfer:memory-map:read::@var{offset},@var{length}
@anchor{qXfer memory map read}
Access the target's @dfn{memory-map}. @xref{Memory Map Format}. The
@table @samp
-@item F@var{retcode},@var{errno},@var{Ctrl-C flag};@var{call-specific
-attachment}
+@item F@var{retcode},@var{errno},@var{Ctrl-C flag};@var{call-specific attachment}
@var{retcode} is the return code of the system call as hexadecimal value.
<- @code{T02}
@end smallexample
+@node Library List Format
+@section Library List Format
+@cindex library list format, remote protocol
+
+On some platforms, a dynamic loader (e.g.@: @file{ld.so}) runs in the
+same process as your application to manage libraries. In this case,
+@value{GDBN} can use the loader's symbol table and normal memory
+operations to maintain a list of shared libraries. On other
+platforms, the operating system manages loaded libraries.
+@value{GDBN} can not retrieve the list of currently loaded libraries
+through memory operations, so it uses the @samp{qXfer:libraries:read}
+packet (@pxref{qXfer library list read}) instead. The remote stub
+queries the target's operating system and reports which libraries
+are loaded.
+
+The @samp{qXfer:libraries:read} packet returns an XML document which
+lists loaded libraries and their offsets. Each library has an
+associated name and one or more segment base addresses, which report
+where the library was loaded in memory. The segment bases are start
+addresses, not relocation offsets; they do not depend on the library's
+link-time base addresses.
+
+A simple memory map, with one loaded library relocated by a single
+offset, looks like this:
+
+@smallexample
+<library-list>
+ <library name="/lib/libc.so.6">
+ <segment address="0x10000000"/>
+ </library>
+</library-list>
+@end smallexample
+
+The format of a library list is described by this DTD:
+
+@smallexample
+<!-- library-list: Root element with versioning -->
+<!ELEMENT library-list (library)*>
+<!ATTLIST library-list version CDATA #FIXED "1.0">
+<!ELEMENT library (segment)*>
+<!ATTLIST library name CDATA #REQUIRED>
+<!ELEMENT segment EMPTY>
+<!ATTLIST segment address CDATA #REQUIRED>
+@end smallexample
+
@node Memory Map Format
@section Memory Map Format
@cindex memory map format
of recognizing standard features, but @value{GDBN} will only display
registers using the capitalization used in the description.
+@menu
+* ARM Features::
+* M68K Features::
+@end menu
+
+
+@node ARM Features
@subsection ARM Features
@cindex target descriptions, ARM features
contain a single register, @samp{restart}, which is used by the
Linux kernel to control restartable syscalls.
+@node M68K Features
+@subsection M68K Features
+@cindex target descriptions, M68K features
+
+@table @code
+@item @samp{org.gnu.gdb.m68k.core}
+@itemx @samp{org.gnu.gdb.coldfire.core}
+@itemx @samp{org.gnu.gdb.fido.core}
+One of those features must be always present.
+The feature that is present determines which flavor of m86k is
+used. The feature that is present should contain registers
+@samp{d0} through @samp{d7}, @samp{a0} through @samp{a5}, @samp{fp},
+@samp{sp}, @samp{ps} and @samp{pc}.
+
+@item @samp{org.gnu.gdb.coldfire.fp}
+This feature is optional. If present, it should contain registers
+@samp{fp0} through @samp{fp7}, @samp{fpcontrol}, @samp{fpstatus} and
+@samp{fpiaddr}.
+@end table
+
@include gpl.texi
@raisesections
projects / deliverable / binutils-gdb.git / blobdiff