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?


> Date: Tue, 15 Jan 2008 22:40:22 +0100 (CET)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: brobecker@adacore.com (Joel Brobecker), msnyder@specifix.com,
>         mark.kettenis@xs4all.nl, gdb-patches@sourceware.org
> 
> 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
> 


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