This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/RFA?] Should break FILE:LINENO skip prologue?


> Cc: mark.kettenis@xs4all.nl,  uweigand@de.ibm.com,  brobecker@adacore.com,
> 	  msnyder@specifix.com,  gdb-patches@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Thu, 17 Jan 2008 10:37:57 -0800
> 
> 
> Eli Zaretskii <eliz at gnu.org> writes:
> >> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,  uweigand@de.ibm.com,
> >> 	  brobecker@adacore.com,  msnyder@specifix.com,
> >> 	  gdb-patches@sourceware.org
> >> From: Jim Blandy <jimb@codesourcery.com>
> >> Date: Wed, 16 Jan 2008 13:36:11 -0800
> >> 
> >> GDB allows 'FILENAME'::FUNCTION in C expressions:
> >
> > Thanks.
> >
> > But if "break *'FILENAME'::FUNCTION" works, why is it wrong to expect
> > that "break *FILENAME:FUNCTION" should also work.  None of them is a
> > valid C expression, it's just something GDB does to help the user,
> > right?
> 
> Our goal here is for GDB to provide memorable, predictable, terse ways
> for people to describe locations for breakpoints, listings, and so on.
> There should be terse, memorable ways to specify every form one needs
> in daily use.  The '*EXPRESSION' form is an escape hatch for those
> cases that fall outside daily use.
> 
> Setting breakpoints in functions before stack frame and argument setup
> instructions is an obscure corner case that only people writing or
> generating assembly code (say, compiler authors) or people working on
> GDB need.  The '*EXPRESSION' escape hatch syntax is adequate for such
> users.
> 
> To make 'break *FILENAME:FUNCTION' work, there are two approaches:
> 
> - We could extend GDB's C grammar to treat 'FILENAME:FUNCTION' as a
>   valid expression.  However, if not quoted, many FILENAMES would be
>   ambiguous with other C expressions --- for example, is foo.c a
>   filename, or a reference to the member 'c' of a structure or union
>   'foo'?  If that problem could be resolved, the use of ':' would
>   still be ambiguous with the ?: operator.
> 
> - We could extend the linespec syntax to recognize
>   '*FILENAME:FUNCTION' specially, and not try to parse
>   'FILENAME:FUNCTION' as an expression.
> 
> But who does this serve?  The people setting breakpoints at function
> entry points won't find this helpful, as it just introduces
> ambiguities and special cases into a grammar that already does the job
> for them.  And other users don't want to set breakpoints there.

Okay, I'm obviously in disagreement here with several other
maintainers, and I'm tired of arguing about this.  So I went out and
documented the current behavior with the patch below.  Comments are
welcome.

Committed.


2008-01-19  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Specify Location): New section.
	(Delete Breaks, Edit, Set Breaks): Remove description of
	locations.  Instead, add a reference to "Specify Location".
	(Machine Code, Jumping, Thread Stops, Continuing and Stepping)
	(Symbols): Refer to "Specify Location" for the valid forms of
	linespecs and locations.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.457
diff -u -r1.457 gdb.texinfo
--- gdb.texinfo	12 Jan 2008 08:36:09 -0000	1.457
+++ gdb.texinfo	19 Jan 2008 13:35:53 -0000
@@ -2836,41 +2836,18 @@
 Vars,, Convenience Variables}, for a discussion of what you can do with
 convenience variables.
 
-You have several ways to say where the breakpoint should go.
-
 @table @code
-@item break @var{function}
-Set a breakpoint at entry to function @var{function}.
+@item break @var{location}
+Set a breakpoint at the given @var{location}, which can specify a
+function name, a line number, or an address of an instruction.
+(@xref{Specify Location}, for a list of all the possible ways to
+specify a @var{location}.)  The breakpoint will stop your program just
+before it executes any of the code in the specified @var{location}.
+
 When using source languages that permit overloading of symbols, such as
-C@t{++}, @var{function} may refer to more than one possible place to break.
+C@t{++}, a function name may refer to more than one possible place to break.
 @xref{Breakpoint Menus,,Breakpoint Menus}, for a discussion of that situation.
 
-@item break +@var{offset}
-@itemx break -@var{offset}
-Set a breakpoint some number of lines forward or back from the position
-at which execution stopped in the currently selected @dfn{stack frame}.
-(@xref{Frames, ,Frames}, for a description of stack frames.)
-
-@item break @var{linenum}
-Set a breakpoint at line @var{linenum} in the current source file.
-The current source file is the last file whose source text was printed.
-The breakpoint will stop your program just before it executes any of the
-code on that line.
-
-@item break @var{filename}:@var{linenum}
-Set a breakpoint at line @var{linenum} in source file @var{filename}.
-
-@item break @var{filename}:@var{function}
-Set a breakpoint at entry to function @var{function} found in file
-@var{filename}.  Specifying a file name as well as a function name is
-superfluous except when multiple files contain similarly named
-functions.
-
-@item break *@var{address}
-Set a breakpoint at address @var{address}.  You can use this to set
-breakpoints in parts of your program which do not have debugging
-information or source files.
-
 @item break
 When called without any arguments, @code{break} sets a breakpoint at
 the next instruction to be executed in the selected stack frame
@@ -2926,7 +2903,6 @@
 breakpoints @value{GDBN} will use, see @ref{set remote
 hardware-breakpoint-limit}.
 
-
 @kindex thbreak
 @item thbreak @var{args}
 Set a hardware-assisted breakpoint enabled only for one stop.  @var{args}
@@ -3520,6 +3496,12 @@
 the innermost frame is selected, this is a good way to delete a
 breakpoint where your program just stopped.
 
+@item clear @var{location}
+Delete any breakpoints set at the specified @var{location}.
+@xref{Specify Location}, for the various forms of @var{location}; the
+most useful ones are listed below:
+
+@table @code
 @item clear @var{function}
 @itemx clear @var{filename}:@var{function}
 Delete any breakpoints set at entry to the named @var{function}.
@@ -3528,6 +3510,7 @@
 @itemx clear @var{filename}:@var{linenum}
 Delete any breakpoints set at or within the code of the specified
 @var{linenum} of the specified @var{filename}.
+@end table
 
 @cindex delete breakpoints
 @kindex delete
@@ -4158,8 +4141,8 @@
 @itemx u @var{location}
 Continue running your program until either the specified location is
 reached, or the current stack frame returns.  @var{location} is any of
-the forms of argument acceptable to @code{break} (@pxref{Set Breaks,
-,Setting Breakpoints}).  This form of the command uses breakpoints, and
+the forms described in @ref{Specify Location}.
+This form of the command uses temporary breakpoints, and
 hence is quicker than @code{until} without an argument.  The specified
 location is actually reached only if it is in the current frame.  This
 implies that @code{until} can be used to skip over recursive function
@@ -4182,8 +4165,9 @@
 @kindex advance @var{location}
 @itemx advance @var{location}
 Continue running the program up to the given @var{location}.  An argument is
-required, which should be of the same form as arguments for the @code{break}
-command.  Execution will also stop upon exit from the current stack
+required, which should be of one of the forms described in
+@ref{Specify Location}.
+Execution will also stop upon exit from the current stack
 frame.  This command is similar to @code{until}, but @code{advance} will
 not skip over recursive function calls, and the target location doesn't
 have to be in the same frame as the current one.
@@ -4341,7 +4325,8 @@
 @item break @var{linespec} thread @var{threadno}
 @itemx break @var{linespec} thread @var{threadno} if @dots{}
 @var{linespec} specifies source lines; there are several ways of
-writing them, but the effect is always to specify some source line.
+writing them (@pxref{Specify Location}), but the effect is always to
+specify some source line.
 
 Use the qualifier @samp{thread @var{threadno}} with a breakpoint command
 to specify that you only want @value{GDBN} to stop the program when a
@@ -4904,6 +4889,7 @@
 
 @menu
 * List::                        Printing source lines
+* Specify Location::            How to specify code locations
 * Edit::                        Editing source files
 * Search::                      Searching source files
 * Source Path::                 Specifying source directories
@@ -4917,7 +4903,8 @@
 @kindex l @r{(@code{list})}
 To print lines from a source file, use the @code{list} command
 (abbreviated @code{l}).  By default, ten lines are printed.
-There are several ways to specify what part of the file you want to print.
+There are several ways to specify what part of the file you want to
+print; see @ref{Specify Location}, for the full list.
 
 Here are the forms of the @code{list} command most commonly used:
 
@@ -4962,10 +4949,11 @@
 argument of @samp{-}; that argument is preserved in repetition so that
 each repetition moves up in the source file.
 
-@cindex linespec
 In general, the @code{list} command expects you to supply zero, one or two
 @dfn{linespecs}.  Linespecs specify source lines; there are several ways
-of writing them, but the effect is always to specify some source line.
+of writing them (@pxref{Specify Location}), but the effect is always
+to specify some source line.
+
 Here is a complete description of the possible arguments for @code{list}:
 
 @table @code
@@ -4974,7 +4962,9 @@
 
 @item list @var{first},@var{last}
 Print lines from @var{first} to @var{last}.  Both arguments are
-linespecs.
+linespecs.  When a @code{list} command has two linespecs, and the
+source file of the second linespec is omitted, this refers to
+the same source file as the first linespec.
 
 @item list ,@var{last}
 Print lines ending with @var{last}.
@@ -4992,42 +4982,86 @@
 As described in the preceding table.
 @end table
 
-Here are the ways of specifying a single source line---all the
-kinds of linespec.
+@node Specify Location
+@section Specifying a Location
+@cindex specifying location
+@cindex linespec
 
-@table @code
-@item @var{number}
-Specifies line @var{number} of the current source file.
-When a @code{list} command has two linespecs, this refers to
-the same source file as the first linespec.
+Several @value{GDBN} commands accept arguments that specify a location
+of your program's code.  Since @value{GDBN} is a source-level
+debugger, a location usually specifies some line in the source code;
+for that reason, locations are also known as @dfn{linespecs}.
+
+Here are all the different ways of specifying a code location that
+@value{GDBN} understands:
 
-@item +@var{offset}
-Specifies the line @var{offset} lines after the last line printed.
-When used as the second linespec in a @code{list} command that has
-two, this specifies the line @var{offset} lines down from the
-first linespec.
+@table @code
+@item @var{linenum}
+Specifies the line number @var{linenum} of the current source file.
 
 @item -@var{offset}
-Specifies the line @var{offset} lines before the last line printed.
+@itemx +@var{offset}
+Specifies the line @var{offset} lines before or after the @dfn{current
+line}.  For the @code{list} command, the current line is the last one
+printed; for the breakpoint commands, this is the line at which
+execution stopped in the currently selected @dfn{stack frame}
+(@pxref{Frames, ,Frames}, for a description of stack frames.)  When
+used as the second of the two linespecs in a @code{list} command,
+this specifies the line @var{offset} lines up or down from the first
+linespec.
 
-@item @var{filename}:@var{number}
-Specifies line @var{number} in the source file @var{filename}.
+@item @var{filename}:@var{linenum}
+Specifies the line @var{linenum} in the source file @var{filename}.
 
 @item @var{function}
 Specifies the line that begins the body of the function @var{function}.
-For example: in C, this is the line with the open brace.
+For example, in C, this is the line with the open brace.
 
 @item @var{filename}:@var{function}
-Specifies the line of the open-brace that begins the body of the
-function @var{function} in the file @var{filename}.  You only need the
-file name with a function name to avoid ambiguity when there are
-identically named functions in different source files.
+Specifies the line that begins the body of the function @var{function}
+in the file @var{filename}.  You only need the file name with a
+function name to avoid ambiguity when there are identically named
+functions in different source files.
 
 @item *@var{address}
-Specifies the line containing the program address @var{address}.
-@var{address} may be any expression.
+Specifies the program address @var{address}.  For line-oriented
+commands, such as @code{list} and @code{edit}, this specifies a source
+line that contains @var{address}.  For @code{break} and other
+breakpoint oriented commands, this can be used to set breakpoints in
+parts of your program which do not have debugging information or
+source files.
+
+Here @var{address} may be any expression valid in the current working
+language (@pxref{Languages, working language}) that specifies a code
+address.  As a convenience, @value{GDBN} extends the semantics of
+expressions used in locations to cover the situations that frequently
+happen during debugging.  Here are the various forms of @var{address}:
+
+@table @code
+@item @var{expression}
+Any expression valid in the current working language.
+
+@item @var{funcaddr}
+An address of a function or procedure derived from its name.  In C,
+C@t{++}, Java, Objective-C, Fortran, minimal, and assembly, this is
+simply the function's name @var{function} (and actually a special case
+of a valid expression).  In Pascal and Modula-2, this is
+@code{&@var{function}}.  In Ada, this is @code{@var{function}'Address}
+(although the Pascal form also works).
+
+This form specifies the address of the function's first instruction,
+before the stack frame and arguments have been set up.
+
+@item '@var{filename}'::@var{funcaddr}
+Like @var{funcaddr} above, but also specifies the name of the source
+file explicitly.  This is useful if the name of the function does not
+specify the function unambiguously, e.g., if there are several
+functions with identical names in different source files.
+@end table
+
 @end table
 
+
 @node Edit
 @section Editing Source Files
 @cindex editing source files
@@ -5039,32 +5073,24 @@
 is invoked with the current line set to
 the active line in the program.
 Alternatively, there are several ways to specify what part of the file you
-want to print if you want to see other parts of the program.
-
-Here are the forms of the @code{edit} command most commonly used:
+want to print if you want to see other parts of the program:
 
 @table @code
-@item edit
-Edit the current source file at the active line number in the program.
+@item edit @var{location}
+Edit the source file specified by @code{location}.  Editing starts at
+that @var{location}, e.g., at the specified source line of the
+specified file.  @xref{Specify Location}, for all the possible forms
+of the @var{location} argument; here are the forms of the @code{edit}
+command most commonly used:
 
+@table @code
 @item edit @var{number}
 Edit the current source file with @var{number} as the active line number.
 
 @item edit @var{function}
 Edit the file containing @var{function} at the beginning of its definition.
+@end table
 
-@item edit @var{filename}:@var{number}
-Specifies line @var{number} in the source file @var{filename}.
-
-@item edit @var{filename}:@var{function}
-Specifies the line that begins the body of the
-function @var{function} in the file @var{filename}.  You only need the
-file name with a function name to avoid ambiguity when there are
-identically named functions in different source files.
-
-@item edit *@var{address}
-Specifies the line containing the program address @var{address}.
-@var{address} may be any expression.
 @end table
 
 @subsection Choosing your Editor
@@ -5335,8 +5361,7 @@
 @item info line @var{linespec}
 Print the starting and ending addresses of the compiled code for
 source line @var{linespec}.  You can specify source lines in any of
-the ways understood by the @code{list} command (@pxref{List, ,Printing
-Source Lines}).
+the ways documented in @ref{Specify Location}.
 @end table
 
 For example, we can use @code{info line} to discover the location of
@@ -10988,7 +11013,8 @@
 List all the variables local to a particular scope.  This command
 accepts a @var{location} argument---a function name, a source line, or
 an address preceded by a @samp{*}, and prints all the variables local
-to the scope defined by that location.  For example:
+to the scope defined by that location.  (@xref{Specify Location}, for
+details about supported forms of @var{location}.)  For example:
 
 @smallexample
 (@value{GDBP}) @b{info scope command_line_handler}
@@ -11358,12 +11384,13 @@
 @table @code
 @kindex jump
 @item jump @var{linespec}
-Resume execution at line @var{linespec}.  Execution stops again
-immediately if there is a breakpoint there.  @xref{List, ,Printing
-Source Lines}, for a description of the different forms of
-@var{linespec}.  It is common practice to use the @code{tbreak} command
-in conjunction with @code{jump}.  @xref{Set Breaks, ,Setting
-Breakpoints}.
+@itemx jump @var{location}
+Resume execution at line @var{linespec} or at address given by
+@var{location}.  Execution stops again immediately if there is a
+breakpoint there.  @xref{Specify Location}, for a description of the
+different forms of @var{linespec} and @var{location}.  It is common
+practice to use the @code{tbreak} command in conjunction with
+@code{jump}.  @xref{Set Breaks, ,Setting Breakpoints}.
 
 The @code{jump} command does not change the current stack frame, or
 the stack pointer, or the contents of any memory location or any
@@ -11374,9 +11401,6 @@
 confirmation if the specified line is not in the function currently
 executing.  However, even bizarre results are predictable if you are
 well acquainted with the machine-language code of your program.
-
-@item jump *@var{address}
-Resume execution at the instruction at address @var{address}.
 @end table
 
 @c Doesn't work on HP-UX; have to set $pcoqh and $pcoqt.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]