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

Ulrich Weigand uweigand@de.ibm.com
Tue Jan 15 21:40:00 GMT 2008


Eli Zaretskii wrote:
> > Date: Tue, 15 Jan 2008 04:38:32 -0800
> > From: Joel Brobecker <brobecker@adacore.com>
> > 
> > > By the way, has anyone tried *FILENAME:FUNCTION?  I'm surprised that
> > > works, since it would have to be part of the C parser.
> > 
> > Confirmed - it doesn't work.
> 
> Which is a bug, IMO: if FUNCTION works, so should FILENAME:FUNCTION,
> otherwise GDB is inconsistent in its treatment of locations specs.

Actually, I disagree that this is inconsistent.  The point is that
the EXPRESSION part of a *EXPRESSION location spec is *not* itself
a location spec, but an *expression*.

The set of valid expressions varies with the language, but none of
them support any string of the form FILENAME:FUNCTION as expression.
However, for *some* languages (e.g. C, but not Ada), a function name
happens to be a valid expression that evaluates to the address of
that function.  It is only due to that "accident" that 
  break *FUNCTION
does indeed set a breakpoint at the address of FUNCTION (assuming
the current language is C).

On the other hand, if FP happens to be the name of a function pointer
variable, break *FP will -by the same rules- set a break point on the
function currently pointed to (while "break FP" does not work at all).

So, in short, I fully agree with the point raised by Mark that
  *FUNCTION
should *not* be documented as a feature of location specs, because
*there is no such feature*.  The feature that actually exists is
  *EXPRESSION
where EXPRESSION is simply any expression of the current language
that is evaluated to result in a machine address.

(Of course, there could be examples of typical usage of that feature
that explain the idiom to use *FUNCTION while in the C language, and
how that differs in practice from using FUNCTION as a location spec.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com



More information about the Gdb-patches mailing list