From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1086) id E5748384F01E; Thu, 2 Jun 2022 16:36:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E5748384F01E Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Eli Zaretskii To: gdb-cvs@sourceware.org Subject: [binutils-gdb] Rearrange and slightly reword the "Location Specification" section X-Act-Checkin: binutils-gdb X-Git-Author: Eli Zaretskii X-Git-Refname: refs/heads/master X-Git-Oldrev: 527907e0e61e50708b1bbdcc95cf53b6b9562217 X-Git-Newrev: 0c8cd1de90b97f12b27b40c2922a03a68932eea1 Message-Id: <20220602163616.E5748384F01E@sourceware.org> Date: Thu, 2 Jun 2022 16:36:16 +0000 (GMT) X-BeenThere: gdb-cvs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 16:36:17 -0000 https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D0c8cd1de90b9= 7f12b27b40c2922a03a68932eea1 commit 0c8cd1de90b97f12b27b40c2922a03a68932eea1 Author: Eli Zaretskii Date: Thu Jun 2 19:34:15 2022 +0300 Rearrange and slightly reword the "Location Specification" section =20 This rearranges and changes the wording of the "Location Specification" section of the GDB manual in minor ways. Diff: --- gdb/doc/gdb.texinfo | 129 +++++++++++++++++++++++++-----------------------= ---- 1 file changed, 63 insertions(+), 66 deletions(-) diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 5f09f3a1433..434add3a663 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -9056,73 +9056,68 @@ As described in the preceding table. @node Location Specifications @section Location Specifications @cindex specifying location -@cindex location spec @cindex locspec @cindex source location @cindex code location =20 +@cindex location spec Several @value{GDBN} commands accept arguments that specify a location -or locations of your program's code. Since @value{GDBN} is a -source-level debugger, a location specification usually indicates some -line in the source code, but it can also indicate a function name, an -address, a label, and more. +or locations of your program's code. Many times locations are +specified using a source line number, but they can also be specified +by a function name, an address, a label, etc. The different +forms of specifying a location that @value{GDBN} recognizes are +collectively known as forms of @dfn{location specification}, or +@dfn{location spec}. This section documents the forms of specifying +locations that @value{GDBN} recognizes. + +@cindex location resolution +@cindex resolution of location spec +When you specify a location, @value{GDBN} needs to find the place in +your program, known as @dfn{code location}, that corresponds to the +given location spec. We call this process of finding actual code +locations corresponding to a location spec @dfn{location resolution}. =20 A concrete code location in your program is uniquely identifiable by a -set of logical attributes. A line number, the source file the line -belongs to, the fully-qualified and prototyped function it is defined -in, and an instruction address. Because each inferior has its own -address space, also an inferior number. The source file attribute has -as many directory components as possible, retrieved from the debug -information, and in absolute form if possible, but it may also be in -relative form. - -On the other hand, a @dfn{location specification} (a.k.a.@: -@dfn{location spec}) is a way to find or refer to the concrete code -locations in the program. A location spec serves as a blueprint, and -@value{GDBN} resolves the spec to actual code locations in your -program by using the source and debug information. - -The location spec may be incomplete, and @value{GDBN} will do its best -to find all the locations in the program that match it. - -For example, a location spec may just indicate a line number and a -source filename with no directory components, or even not specify a -filename at all, just a line number. To differentiate between files -with the same base name, the spec may prepend as many directories as -is necessary to uniquely identify the desired file. - -Or, the spec may indicate a simple function name instead of a -fully-qualified and prototyped function name (e.g., @code{func} -instead of @code{A::func(int)}). To differentiate between functions -with the same name, the spec may prepend as many class and namespace -names as is necessary to uniquely identify the desired function, -and/or it may specify the function parameters as well. In addition, -the spec may indicate that the specified function name should be -interpreted as a fully-qualified name. - -You may not have debug info for some of the instructions in the -program, so a resolved code location that itself points to such code -will be incomplete and be missing some attributes, such as the source -file and line number, and sometimes even function names. Such an -incomplete code location is only usable in contexts that work with -addresses and/or function names. Some commands can only work with -complete code locations. - -Here are examples of typical situations that result in a location spec -matching multiple concrete code locations in your program: +set of several attributes: its source line number, the name of its +source file, the fully-qualified and prototyped function in which it +is defined, and an instruction address. Because each inferior has its +own address space, the inferior number is also a necessary part of +these attributes. + +By contrast, location specs you type will many times omit some of +these attributes. For example, it is customary to specify just the +source line number to mean a line in the current source file, or +specify just the basename of the file, omitting its directories. In +other words, a location spec is usually incomplete, a kind of +blueprint, and @value{GDBN} needs to complete the missing attributes +by using the implied defaults, and by considering the source code and +the debug information available to it. This is what location +resolution is about. + +The resolution of an incomplete location spec can produce more than a +single code location, if the spec doesn't allow distinguishing between +them. Here are some examples of situations that result in a location +spec matching multiple code locations in your program: =20 @itemize @bullet @item -The location spec specifies a function name, and multiple functions in -the program may have the same name. +The location spec specifies a function name, and there are several +functions in the program which have that name. (To distinguish +between them, you can specify a fully-qualified and prototyped +function name, such as @code{A::func(int)} instead of just +@code{func}.) =20 @item -The location spec specifies a source file name, and multiple source -files in the program share the same name. +The location spec specifies a source file name, and there are several +source files in the program that share the same name, for example +several files with the same basename in different subdirectories. (To +distinguish between them, specify enough leading directories with the +file name.) =20 @item For a C@t{++} constructor, the @value{NGCC} compiler generates several -instances of the function body, used in different cases. +instances of the function body, used in different cases, but their +source-level names are identical. =20 @item For a C@t{++} template function, a given line in the function can @@ -9130,21 +9125,30 @@ correspond to any number of instantiations. =20 @item For an inlined function, a given source line can correspond to several -places where that function is inlined. +actual code locations with that function's inlined code. @end itemize =20 -And here are examples of typical situations that result in a location -spec matching no code locations in your program at all: +Resolution of a location spec can also fail to produce a complete code +location, or even fail to produce any code location. Here are some +examples of such situations: =20 @itemize @bullet +@item +Some parts of the program lack detailed enough debug info, so the +resolved code location lacks some attributes, like source file name +and line number, leaving just the instruction address and perhaps also +a function name. Such an incomplete code location is only usable in +contexts that work with addresses and/or function names. Some +commands can only work with complete code locations. + @item The location spec specifies a function name, and there are no -functions in the program with that name, or they only exist in a +functions in the program by that name, or they only exist in a yet-unloaded shared library. =20 @item The location spec specifies a source file name, and there are no -source files in the program with that name, or they only exist in a +source files in the program by that name, or they only exist in a yet-unloaded shared library. =20 @item @@ -9154,16 +9158,9 @@ match the file name, none of those files has the spe= cified line number. @end itemize =20 -The act of finding all the actual code locations that match the user -input is called @dfn{resolving the location spec}. The code locations -that @value{GDBN} finds are the @dfn{resolved code locations}. - -If @value{GDBN} cannot find any code location that matches the user -input, it is said that @value{GDBN} could not resolve the location -spec. - Locations may be specified using three different formats: linespec -locations, explicit locations, or address locations. +locations, explicit locations, or address locations. The following +subsections describe these formats. =20 @menu * Linespec Locations:: Linespec locations