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?


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.


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