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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]

Hello,

I would like to revive a discussion that started sometime in 2002.
The idea is the following: When breaking on a given source line, if
that line is inside a function prologue, skip the prologue (using
the linetable to do so).

In our experience, we have found that most users are not aware of
the existence of function prologues. When they break on the line
where a function is defined, they think the debugger is doing the
same thing than it would do if it inserted the breakpoint using
that function name.  Unfortunately, it doesn't and they end up
having problems trying to print parameter values [1].

When we discussed this back in 2002, there wasn't an overwhelming
support for this proposal, but I think that we had mild support.
Both Apple and AdaCore have decided to implement this, and JimB
was also supporting the idea. I searched the archives, and I didn't
really find any negative support. I personally think that it's
friendlier and is usually what the typical user expects.

The only counter argument, IMO, is the fact that we're changing a
behavior that has been there for a long time... But the current
behavior is currently undocumented (or at least it wasn't in 2002
:-), and users can use the "break *FUNC_NAME" syntax if they don't
want the prologue to be skipped. Like Jim, I think this syntax
makes better sense - in fact, I have always naturally used the
*FUNC_NAME syntax in these cases, never really used line numbers.

So I am making this proposal again, with the hope of reaching
a decision, either yes or no. Or, as a compromise, we can control
the behavior through as setting. I would argue for the default value
to change the behavior, since: Deliberately breaking inside the
prologue is a relatively uncommon operation; and the users who expect
to break inside the prologue know what they are doing and will quickly
find a way around.

Here is a prototype that implements the proposal without the switch.
Surprisingly, the code has evolved in a way that it is now very
easy to implement.  Adding the switch would be very simple too.

2008-01-09  Joel Brobecker  <brobecker@adacore.com>

        * breakpoint.c (skip_prologue_sal): New function.
        (resolve_sal_pc): Adjust SAL past prologue if the SAL was
        computed from a line number.

I can write a dedicated testcase or test for this, but I don't think
this will be necessary.  A couple of testcases (ending-run.exp and
mi-break.exp) insert breakpoints on the line where a function is
defined, so they already test that this patch has some effect
(understand the testcases will need to be adjusted or they will
have some FAILS).

Tested on x86-linux. All the changes in the testsuite are expected.

Thoughts?

Thanks,
-- 
Joel

[1]: I think we have made some progress with parameter/variable
     tracking with DWARF, but I think it's not activated by default
     and we also still support platforms where DWARF is not available.

[-- Attachment #2: skip-prologue.diff --]
[-- Type: text/plain, Size: 1275 bytes --]

Index: breakpoint.c
===================================================================
--- breakpoint.c	(revision 117)
+++ breakpoint.c	(revision 118)
@@ -5446,6 +5446,25 @@ gdb_breakpoint (char *address, char *con
 			       0);
 }
 
+/* Adjust SAL to the first instruction past the function prologue.
+   The end of the prologue is determined using the line table from
+   the debugging information.
+
+   If SAL is already past the prologue, then do nothing.  */
+
+static void
+skip_prologue_sal (struct symtab_and_line *sal)
+{
+  struct symbol *sym = find_pc_function (sal->pc);
+  struct symtab_and_line start_sal;
+
+  if (sym == NULL)
+    return;
+
+  start_sal = find_function_start_sal (sym, 1);
+  if (sal->pc < start_sal.pc)
+    *sal = start_sal;
+}
 
 /* Helper function for break_command_1 and disassemble_command.  */
 
@@ -5460,6 +5479,11 @@ resolve_sal_pc (struct symtab_and_line *
 	error (_("No line %d in file \"%s\"."),
 	       sal->line, sal->symtab->filename);
       sal->pc = pc;
+
+      /* If this SAL corresponds to a breakpoint inserted using
+         a line number, then skip the function prologue if necessary.  */
+      if (sal->explicit_line)
+        skip_prologue_sal (sal);
     }
 
   if (sal->section == 0 && sal->symtab != NULL)

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

[Jim Blandy]

Joel Brobecker <brobecker at adacore.com> writes:
> I would like to revive a discussion that started sometime in 2002.
> The idea is the following: When breaking on a given source line, if
> that line is inside a function prologue, skip the prologue (using
> the linetable to do so).
>
> In our experience, we have found that most users are not aware of
> the existence of function prologues. When they break on the line
> where a function is defined, they think the debugger is doing the
> same thing than it would do if it inserted the breakpoint using
> that function name.  Unfortunately, it doesn't and they end up
> having problems trying to print parameter values [1].
>
> When we discussed this back in 2002, there wasn't an overwhelming
> support for this proposal, but I think that we had mild support.
> Both Apple and AdaCore have decided to implement this, and JimB
> was also supporting the idea. I searched the archives, and I didn't
> really find any negative support. I personally think that it's
> friendlier and is usually what the typical user expects.
>
> The only counter argument, IMO, is the fact that we're changing a
> behavior that has been there for a long time... But the current
> behavior is currently undocumented (or at least it wasn't in 2002
> :-), and users can use the "break *FUNC_NAME" syntax if they don't
> want the prologue to be skipped. Like Jim, I think this syntax
> makes better sense - in fact, I have always naturally used the
> *FUNC_NAME syntax in these cases, never really used line numbers.
>
> So I am making this proposal again, with the hope of reaching
> a decision, either yes or no. Or, as a compromise, we can control
> the behavior through as setting. I would argue for the default value
> to change the behavior, since: Deliberately breaking inside the
> prologue is a relatively uncommon operation; and the users who expect
> to break inside the prologue know what they are doing and will quickly
> find a way around.

I don't remember the original conversation, but the suggestion still
sounds like a good idea to me.  (Whew!)

> [1]: I think we have made some progress with parameter/variable
>      tracking with DWARF, but I think it's not activated by default
>      and we also still support platforms where DWARF is not available.

What is "not activated by default", exactly?  Is it in GCC?  In GDB?
Where in GDB?

I've long had this dream that eventually we would just stop skipping
prologues altogether, because everything would actually work at every
instruction in the function.

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

[Mark Kettenis]

> Date: Wed, 9 Jan 2008 07:17:45 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Hello,
> 
> I would like to revive a discussion that started sometime in 2002.
> The idea is the following: When breaking on a given source line, if
> that line is inside a function prologue, skip the prologue (using
> the linetable to do so).

You've got me confused here.  How can it be that if skipping using the
line table helps, the breakpoint location (which I assume has been
determined based on the line table) isn't right to begin with?

> In our experience, we have found that most users are not aware of
> the existence of function prologues. When they break on the line
> where a function is defined, they think the debugger is doing the
> same thing than it would do if it inserted the breakpoint using
> that function name.  Unfortunately, it doesn't and they end up
> having problems trying to print parameter values [1].

Ultimately, the problem is that GCC is (still) generating the wrong
debug information, since either:

 * The line table is wrong and the prologue instructions are wrongly
   attributed to a line of source code.

 * Instructions corresponding to source code have been scheduled into
   the prologue, but the compiler didn't generate location expressions
   for the arguments that are valid at that point.

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

[Daniel Jacobowitz]

On Wed, Jan 09, 2008 at 11:10:49AM -0800, Jim Blandy wrote:
> > [1]: I think we have made some progress with parameter/variable
> >      tracking with DWARF, but I think it's not activated by default
> >      and we also still support platforms where DWARF is not available.
> 
> What is "not activated by default", exactly?  Is it in GCC?  In GDB?
> Where in GDB?

GCC does not generate the necessary location lists at -O0.  Eric
B. tried at one point; I don't remember if there were bugs, or just
unacceptable bloat.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> I don't remember the original conversation, but the suggestion still
> sounds like a good idea to me.  (Whew!)

Cool! (double whew ;-)

> > [1]: I think we have made some progress with parameter/variable
> >      tracking with DWARF, but I think it's not activated by default
> >      and we also still support platforms where DWARF is not available.
> 
> What is "not activated by default", exactly?  Is it in GCC?  In GDB?
> Where in GDB?

I think it's in GCC. I am not a GCC expert, so I might be wrong,
but I think that the option is -fvar-tracking.  Eric Botcazou told
me about this option when debugging at -O1 or -O2, but apparently,
it has some drawbacks (for now, at least). IIUC, it had to do with
the fact that the optimizers have do so much work that it's hard
to relate back to the original source code entity.

> I've long had this dream that eventually we would just stop skipping
> prologues altogether, because everything would actually work at every
> instruction in the function.

Me too, but I think we're still quite a long ways away from this
happening. There is also the case of stabs, that is still, despite
a lot of effort from many people (including AdaCore), not extinct.

-- 
Joel

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

[Joel Brobecker]

[quoting a bit more to give Eric more context]

On Wed, Jan 09, 2008 at 02:15:35PM -0500, Daniel Jacobowitz wrote:
> On Wed, Jan 09, 2008 at 11:10:49AM -0800, Jim Blandy wrote:
> > > [1]: I think we have made some progress with parameter/variable
> > >      tracking with DWARF, but I think it's not activated by default
> > >      and we also still support platforms where DWARF is not available.
> > 
> > What is "not activated by default", exactly?  Is it in GCC?  In GDB?
> > Where in GDB?
> 
> GCC does not generate the necessary location lists at -O0.  Eric
> B. tried at one point; I don't remember if there were bugs, or just
> unacceptable bloat.

Eric? Can you remind us of what the problems were? I think it was
a combination of both...

-- 
Joel

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

[Joel Brobecker]

> > I would like to revive a discussion that started sometime in 2002.
> > The idea is the following: When breaking on a given source line, if
> > that line is inside a function prologue, skip the prologue (using
> > the linetable to do so).
> 
> You've got me confused here.  How can it be that if skipping using the
> line table helps, the breakpoint location (which I assume has been
> determined based on the line table) isn't right to begin with?

Actually, the line table *is* correct.

Assuming the following code:

    1 void
    2 call_me (int number)
    3 {
    4   dial (number);

Typically, the linetable will have the following entries:

    line 3: <function prologue>
    line 4: <code for call to dial>
    etc...

What I'd like GDB to do is, when the user decides to break on line
2 or 3, to find the address of line 3, realize that it is in the
function prologue, and then skip line 3 until finding the "first
line of real code" (in this case, it's easy, line 4).

Since we are breaking by line number in this case, we know we have
a linetable for our function, and finding the "first line of real
code" (sic from symtab.c:find_function_start_sal description) is
more robust when you rely on debugging info than on prologue scanning.

> Ultimately, the problem is that GCC is (still) generating the wrong
> debug information, since either:

I completely agree, but I don't think the compiler is going to be
fixed anytime soon. I propose to be pragmatic and modify the GDB
behavior so that we do a more useful job with what we have now.
Eventually, when we have better debugging info, we can stop skipping
the function prologue in all cases if we want.

As an aside, I have to say that I find the prologue skipping extremely
convenient regardless of parameter display, because the large majority
of the time, I don't want to stop before the prologue only to have to
"next/step" over it right after.  I'd rather stop in the function body
immediately.  So removing the prologue skipping would be a regression
in usability in my opinion.

-- 
Joel

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

[Michael Snyder]

OK, I'll be the devil's advocate.

By habit and actual practice, if I tell gdb to set a breakpoint
at the opening brace of a function, it is because I want it to
stop before the prologue.

If I tell gdb to set a breakpoint AFTER local variable x
is initialized, but BEFORE local variable y is initialized,
as in the following example...

  int foo()
  {
     int x = 12;
     char *y = "bar";

it is because I want gdb to stop after x is initialized
and before y is initialized.

If gdb decided not to LET me stop in the middle of the
prologue, I would be exceedingly pissed off.


On Wed, 2008-01-09 at 07:17 -0800, Joel Brobecker wrote:
> Hello,
> 
> I would like to revive a discussion that started sometime in 2002.
> The idea is the following: When breaking on a given source line, if
> that line is inside a function prologue, skip the prologue (using
> the linetable to do so).
> 
> In our experience, we have found that most users are not aware of
> the existence of function prologues. When they break on the line
> where a function is defined, they think the debugger is doing the
> same thing than it would do if it inserted the breakpoint using
> that function name.  Unfortunately, it doesn't and they end up
> having problems trying to print parameter values [1].
> 
> When we discussed this back in 2002, there wasn't an overwhelming
> support for this proposal, but I think that we had mild support.
> Both Apple and AdaCore have decided to implement this, and JimB
> was also supporting the idea. I searched the archives, and I didn't
> really find any negative support. I personally think that it's
> friendlier and is usually what the typical user expects.
> 
> The only counter argument, IMO, is the fact that we're changing a
> behavior that has been there for a long time... But the current
> behavior is currently undocumented (or at least it wasn't in 2002
> :-), and users can use the "break *FUNC_NAME" syntax if they don't
> want the prologue to be skipped. Like Jim, I think this syntax
> makes better sense - in fact, I have always naturally used the
> *FUNC_NAME syntax in these cases, never really used line numbers.
> 
> So I am making this proposal again, with the hope of reaching
> a decision, either yes or no. Or, as a compromise, we can control
> the behavior through as setting. I would argue for the default value
> to change the behavior, since: Deliberately breaking inside the
> prologue is a relatively uncommon operation; and the users who expect
> to break inside the prologue know what they are doing and will quickly
> find a way around.
> 
> Here is a prototype that implements the proposal without the switch.
> Surprisingly, the code has evolved in a way that it is now very
> easy to implement.  Adding the switch would be very simple too.
> 
> 2008-01-09  Joel Brobecker  <brobecker@adacore.com>
> 
>         * breakpoint.c (skip_prologue_sal): New function.
>         (resolve_sal_pc): Adjust SAL past prologue if the SAL was
>         computed from a line number.
> 
> I can write a dedicated testcase or test for this, but I don't think
> this will be necessary.  A couple of testcases (ending-run.exp and
> mi-break.exp) insert breakpoints on the line where a function is
> defined, so they already test that this patch has some effect
> (understand the testcases will need to be adjusted or they will
> have some FAILS).
> 
> Tested on x86-linux. All the changes in the testsuite are expected.
> 
> Thoughts?
> 
> Thanks,

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

[Joel Brobecker]

First of all, thanks for your feedback.

> If gdb decided not to LET me stop in the middle of the
> prologue, I would be exceedingly pissed off.

Everyone that I have polled so far told me that they used the
"break *function_name" syntax to break at the beginning of the
prologue. So GDB would not preventing you from doing it.

I know that I will never be able to make everyone happy. I am
just trying to make GDB more consistent and more useful to
most average users, hopefully without hurting the low-level
hackers too much. I'm hoping that the fact that breaking at
the beginning of the prologue is sufficiently uncommon that
the change will be bearable for those who relied on this
behavior.

But that being said, I also proposed if the pain level was perceived
to be too high to introduce a switch that allows the user to select
which behavior he wants...

-- 
Joel

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

[Eric Botcazou]

> Eric? Can you remind us of what the problems were? I think it was
> a combination of both...

Correct.  Bloat + holes in location lists so variables couldn't always be 
displayed in the debugger, what we deemed unacceptable at -O0.  We have a
local patch instead to manually emit location notes in a specific case.

-- 
Eric Botcazou

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

[Michael Snyder]

On Wed, 2008-01-09 at 12:34 -0800, Joel Brobecker wrote:
> First of all, thanks for your feedback.
> 
> > If gdb decided not to LET me stop in the middle of the
> > prologue, I would be exceedingly pissed off.
> 
> Everyone that I have polled so far told me that they used the
> "break *function_name" syntax to break at the beginning of the
> prologue. So GDB would not preventing you from doing it.

But I habitually do it both ways.

What about with a gui?  The gui way of doing this
would be to click on the line with the opening curly-brace.


> I know that I will never be able to make everyone happy. I am
> just trying to make GDB more consistent and more useful to
> most average users, hopefully without hurting the low-level
> hackers too much.

Sure, I appreciate that -- just speaking up for the other viewpoint.

Don't forget my argument about prologue initializations.
Sometimes those involve function calls.  A user might very
well want to stop AFTER some of those function calls, but
BEFORE others, so he could step into them.

Especially in C++, where some of them would be constructors.

>  I'm hoping that the fact that breaking at
> the beginning of the prologue is sufficiently uncommon that
> the change will be bearable for those who relied on this
> behavior.
> 
> But that being said, I also proposed if the pain level was perceived
> to be too high to introduce a switch that allows the user to select
> which behavior he wants...
> 

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

[Eli Zaretskii]

> From: Michael Snyder <msnyder@specifix.com>
> Cc: gdb-patches@sourceware.org
> Date: Wed, 09 Jan 2008 13:04:55 -0800
> 
> On Wed, 2008-01-09 at 12:34 -0800, Joel Brobecker wrote:
> > First of all, thanks for your feedback.
> > 
> > > If gdb decided not to LET me stop in the middle of the
> > > prologue, I would be exceedingly pissed off.
> > 
> > Everyone that I have polled so far told me that they used the
> > "break *function_name" syntax to break at the beginning of the
> > prologue. So GDB would not preventing you from doing it.
> 
> But I habitually do it both ways.

This means a user option is in order to determine this behavior.

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

[Joel Brobecker]

> What about with a gui?  The gui way of doing this
> would be to click on the line with the opening curly-brace.

Interestingly, the GUI is what started everything on our side.
Average users using a GUI who wanted to break on a function simply
clicked on the line where the function name was located, and
expected things to just work.  A question that I asked myself was:
Why does "break FUNCTION_NAME" skip the prologue and yet "break
FILE:LINENO" (from clicking on the filename) doesn't?

> Sure, I appreciate that -- just speaking up for the other viewpoint.

I understand. I am not denying that the other viewpoint will be negatively
impacted, this is not what I was saying.  Is the positive influence on
the other side large enough that the change is worth it?  The question
is open.  But I think that the fact that Apple made this change, and
that AdaCore also proposed it independently of Apple, shows that the
usage among users of both companies is more in favor of skipping the
prologue.

But if you think that the benefit is not large enough to warrant
the change, then I think that's good feedback, and I'll introduce
a switch and keep the current behavior as the default. I actually
really believe that skipping the prologue is the most useful way
of doing things, but I don't want to sound like I'm pushing hard
for it. I'm happy if we have a switch - just sad that the other
side of the camp doesn't see the light (yet :-P) :-).

-- 
Joel

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

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> A question that I asked myself was: Why does "break FUNCTION_NAME"
> skip the prologue and yet "break FILE:LINENO" (from clicking on the
> filename) doesn't?

That looks quite natural to me.  If I request a breakpoint on a line I
want it to be placed as close as possible to that line.  If I request a
breakpoint on a function, I want it to be set to the first interesting
point in that function.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Mark Kettenis]

> Date: Wed, 9 Jan 2008 20:15:40 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > What about with a gui?  The gui way of doing this
> > would be to click on the line with the opening curly-brace.
> 
> Interestingly, the GUI is what started everything on our side.
> Average users using a GUI who wanted to break on a function simply
> clicked on the line where the function name was located, and
> expected things to just work.  A question that I asked myself was:
> Why does "break FUNCTION_NAME" skip the prologue and yet "break
> FILE:LINENO" (from clicking on the filename) doesn't?

Ah, that puts things in a slightly different perspective.  One could
argue that the problem here isn't in GDB, but in the GUI which really
should respond to the user clicking the function name with setting a
breakpoint on the function instead of putting the breakpoint on a
line.

> > Sure, I appreciate that -- just speaking up for the other viewpoint.
> 
> I understand. I am not denying that the other viewpoint will be negatively
> impacted, this is not what I was saying.  Is the positive influence on
> the other side large enough that the change is worth it?  The question
> is open.  But I think that the fact that Apple made this change, and
> that AdaCore also proposed it independently of Apple, shows that the
> usage among users of both companies is more in favor of skipping the
> prologue.

I get hopelessly frustrated with tools that restrict me from doing
things.  I have no problem with the skipping the prologue if I place
the breakpoint on a function because there is an easy to use way to
put a breakpoint on the first instruction of a function.  But there is
no easy to use alternative for placing a breakpoint on a certain line
"within" the prologue like the case Michael sketched.

> But if you think that the benefit is not large enough to warrant
> the change, then I think that's good feedback, and I'll introduce
> a switch and keep the current behavior as the default. I actually
> really believe that skipping the prologue is the most useful way
> of doing things, but I don't want to sound like I'm pushing hard
> for it. I'm happy if we have a switch - just sad that the other
> side of the camp doesn't see the light (yet :-P) :-).

IMHO adding knobs is not desirable, but if the default is to keep the
current behaviour, I won't object.

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

[Mark Kettenis]

> From: Eric Botcazou <ebotcazou@adacore.com>
> Date: Wed, 9 Jan 2008 21:40:43 +0100
> 
> > Eric? Can you remind us of what the problems were? I think it was
> > a combination of both...
> 
> Correct.  Bloat + holes in location lists so variables couldn't always be 
> displayed in the debugger, what we deemed unacceptable at -O0.  We have a
> local patch instead to manually emit location notes in a specific case.

If generating the right location information for -O0 is too difficult,
perhaps the compiler should make life easier for itself and disable
scheduling instructions into the prologue?

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

[Eric Botcazou]

> If generating the right location information for -O0 is too difficult,
> perhaps the compiler should make life easier for itself and disable
> scheduling instructions into the prologue?

What do you call "scheduling instructions into the prologue" exactly?

-- 
Eric Botcazou

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

[Daniel Jacobowitz]

On Thu, Jan 10, 2008 at 11:58:07AM +0100, Mark Kettenis wrote:
> If generating the right location information for -O0 is too difficult,
> perhaps the compiler should make life easier for itself and disable
> scheduling instructions into the prologue?

It already doesn't do that at -O0.

This part of the thread was about not skipping prologues at all; we
can't do that even with GCC, because the debug info says arguments
live in their stack slots.  But they're in different incoming
locations until the end of the prologue (registers or other stack
slots).  I think we'd want debug info which only specified the
incoming locations and the local stack slots, not every load into a
register - which is probably what GCC tries to produce.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

[I already conceded and moved to a revised proposal where the current
behavior is preserved, but this is an interesting question].

> Ah, that puts things in a slightly different perspective.  One could
> argue that the problem here isn't in GDB, but in the GUI which really
> should respond to the user clicking the function name with setting a
> breakpoint on the function instead of putting the breakpoint on a
> line.

Unfortunately, it's not always possible for the GUI to know that
the user clicked on a function name. The user actually clicked on
a line where a function happens to be defined.  With GNAT, some
information is available for the GUI to use once the program has
been compiled, but not all languages provide that type of info.
This is why your suggestion would be relatively difficult to
implement in a way that would be "intelligent".

Right now, if you take GPS (AdaCore's GUI) as an example, if you
want to break on a function (using its name), you have to use
the contextual menu after right-clicking on the function name.
If you want to click on a specific line, just click on it.
Breaking on a function by name is therefore a little more effort
than breaking on a given line, which explains why most users
just click on line numbers.

-- 
Joel

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

[Daniel Jacobowitz]

On Wed, Jan 09, 2008 at 01:04:55PM -0800, Michael Snyder wrote:
> Don't forget my argument about prologue initializations.
> Sometimes those involve function calls.  A user might very
> well want to stop AFTER some of those function calls, but
> BEFORE others, so he could step into them.
> 
> Especially in C++, where some of them would be constructors.

This argument doesn't apply; local variable initializations are not
part of the function prologue.  GCC will attribute them to the lines
on which they were written.  Only setting up the stack frame and
saving incoming arguments to the stack are part of the prologue.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Daniel Jacobowitz]

On Thu, Jan 10, 2008 at 11:38:29AM +0100, Mark Kettenis wrote:
> I get hopelessly frustrated with tools that restrict me from doing
> things.  I have no problem with the skipping the prologue if I place
> the breakpoint on a function because there is an easy to use way to
> put a breakpoint on the first instruction of a function.  But there is
> no easy to use alternative for placing a breakpoint on a certain line
> "within" the prologue like the case Michael sketched.

I don't like my tools to restrict me, either, but I think this is a
change rather than a restriction.  There are no lines within the
prologue (clicking on local variables as Michael described will stop
after the prologue and any earlier local variables, at least at -O0
and with gcc).  And Eclipse, the only IDE with which I am personally
familiar, lets you type breakpoint expressions.  So you can type
"*function_name" into the breakpoint expression box, and you'll stop
in front of the prologue.

What do you think - is that good enough?

> IMHO adding knobs is not desirable, but if the default is to keep the
> current behaviour, I won't object.

I also would prefer not to add a knob for this.  I don't like knobs
for things that (IMHO) we should simply decide consistently.

Although, if the consensus is to keep the current behavior, at least
an IDE could set the knob automatically (unconditionally).  Then the
user experience will be a little different between a GDB console
presented by Eclipse versus a true GDB console (unfortunate), but the
GUI experience will be more intuitive (fortunate).

-- 
Daniel Jacobowitz
CodeSourcery

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

[Jim Blandy]

Daniel Jacobowitz <drow at false.org> writes:
> On Thu, Jan 10, 2008 at 11:58:07AM +0100, Mark Kettenis wrote:
>> If generating the right location information for -O0 is too difficult,
>> perhaps the compiler should make life easier for itself and disable
>> scheduling instructions into the prologue?
>
> It already doesn't do that at -O0.
>
> This part of the thread was about not skipping prologues at all; we
> can't do that even with GCC, because the debug info says arguments
> live in their stack slots.  But they're in different incoming
> locations until the end of the prologue (registers or other stack
> slots).  

I tried this out on the IA-32.  GCC left my original int and char *
arguments in their incoming stack slots, and GDB printed them
correctly at the function's entry point.  When I changed one argument
to a double, GCC generated code to copy that argument into the local
frame, and GDB couldn't print it properly at the entry point.

> I think we'd want debug info which only specified the
> incoming locations and the local stack slots, not every load into a
> register - which is probably what GCC tries to produce.

That could be a nice solution.  The amount of bloat would depend on
how common those argument moves are in real life; I have no idea.

(I wonder if there is a good way to improve the density of location
lists.  The format seems kind of rigid.)

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

[Jim Blandy]

Michael Snyder <msnyder at specifix.com> writes:
> By habit and actual practice, if I tell gdb to set a breakpoint
> at the opening brace of a function, it is because I want it to
> stop before the prologue.

My feeling is that this usage is not important to support, as it makes
things confusing for most GUI users, and GDB provides another way to
set a breakpoint at a function's exact entry point.

> If I tell gdb to set a breakpoint AFTER local variable x
> is initialized, but BEFORE local variable y is initialized,
> as in the following example...
>
>   int foo()
>   {
>      int x = 12;
>      char *y = "bar";
>
> it is because I want gdb to stop after x is initialized
> and before y is initialized.
> If gdb decided not to LET me stop in the middle of the
> prologue, I would be exceedingly pissed off.

Prologue skipping doesn't affect this, as those initializations are
not considered part of the prologue.  'break foo', which skips the
prologue, will set the breakpoint before the initialization of 'x'.
Have I misunderstood?

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

[Michael Snyder]

On Thu, 2008-01-10 at 12:47 +0100, Eric Botcazou wrote:
> > If generating the right location information for -O0 is too difficult,
> > perhaps the compiler should make life easier for itself and disable
> > scheduling instructions into the prologue?
> 
> What do you call "scheduling instructions into the prologue" exactly?

I wouldn't speak for Mark, but personally I could imagine, say, 
that at -O0 gcc might treat the prologue (whatever we decide
that means) as an atom, and not allow non-prologue instructions
to be shuffled into it.

The next question would be, are automatic variable initializations
part of that atom?

I might say that I personally rarely need to debug the "formal"
prologue (that part that would exist in any (framed/frameless)
function independent of automatics initialization), and when I
do, it's as a tools developer, not as an ordinary debugger user.
Therefore I don't mind having to do something "special".

But the initializations are another story, especially if they
require non-trivial stuff like computations or function calls.
Any user might reasonably want to debug those.  So any change
that made it difficult for a user to debug those (say by forcing
him to set a break at the label) would go against the grain
for me.

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

[Michael Snyder]

On Thu, 2008-01-10 at 10:45 -0500, Daniel Jacobowitz wrote:
> On Wed, Jan 09, 2008 at 01:04:55PM -0800, Michael Snyder wrote:
> > Don't forget my argument about prologue initializations.
> > Sometimes those involve function calls.  A user might very
> > well want to stop AFTER some of those function calls, but
> > BEFORE others, so he could step into them.
> > 
> > Especially in C++, where some of them would be constructors.
> 
> This argument doesn't apply; local variable initializations are not
> part of the function prologue.  GCC will attribute them to the lines
> on which they were written.  Only setting up the stack frame and
> saving incoming arguments to the stack are part of the prologue.

In that event, my concerns are much alleviated.
;-)

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

[Mark Kettenis]

> From: Michael Snyder <msnyder@specifix.com>
> Date: Thu, 10 Jan 2008 13:47:02 -0800
> 
> On Thu, 2008-01-10 at 12:47 +0100, Eric Botcazou wrote:
> > > If generating the right location information for -O0 is too difficult,
> > > perhaps the compiler should make life easier for itself and disable
> > > scheduling instructions into the prologue?
> > 
> > What do you call "scheduling instructions into the prologue" exactly?
> 
> I wouldn't speak for Mark, but personally I could imagine, say, 
> that at -O0 gcc might treat the prologue (whatever we decide
> that means) as an atom, and not allow non-prologue instructions
> to be shuffled into it.
> 
> The next question would be, are automatic variable initializations
> part of that atom?
> 
> I might say that I personally rarely need to debug the "formal"
> prologue (that part that would exist in any (framed/frameless)
> function independent of automatics initialization), and when I
> do, it's as a tools developer, not as an ordinary debugger user.
> Therefore I don't mind having to do something "special".
> 
> But the initializations are another story, especially if they
> require non-trivial stuff like computations or function calls.
> Any user might reasonably want to debug those.  So any change
> that made it difficult for a user to debug those (say by forcing
> him to set a break at the label) would go against the grain
> for me.

I think that the compiler will actually almost never move non-trivial
initializations into the prologue, especially if they involve function
calls.  The prologue is all about putting the origional function
arguments in a safe place, and that needs to be done before you call
other functions that might clobber registers.  So if you have
something like:

int
foo (int i, double d)
{
  int j = 42;
  float f = sin(d);
  ...
}

the first assignment may be scheduled into the prologue, but the
second almost certainly won't.  I don't think anybody will actually
miss the possibility to break on the first assignment.  If we can
somehow ascertain ourselves that indeed we can still put a breakpoint
on the second assignment and have it break before entering sin(), I
think Joels origional diff is actually acceptable.

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

[Eric Botcazou]

> I wouldn't speak for Mark, but personally I could imagine, say,
> that at -O0 gcc might treat the prologue (whatever we decide
> that means) as an atom, and not allow non-prologue instructions
> to be shuffled into it.

The prologue is rather well delimited in GCC and changing that would not be 
easy.  Moreover nothing is shuffled into it at -O0, so what you have at -O0 
is the prologue and only the prologue.

> The next question would be, are automatic variable initializations
> part of that atom?

No, they are not.

-- 
Eric Botcazou

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

[Joel Brobecker]

>   1.  int
>   2.  foo (int i, double d)
>   3.  {
>   4.    int j = 42;
>   5.    float f = sin(d);
>   6.    ...
>   7.  }
> 
> the first assignment may be scheduled into the prologue, but the
> second almost certainly won't.

The prologue should never include any of the local variable assignments.

At -O0, the situation is very clear and easy, as the variable
assignments are always past the prologue. Each variable assignment
has its own line and you can break on them as usual. My patches
will not affect that.

The situation becomes trickier at -O1 and beyond, because parts of
the prologue may be delayed later inside the function body. But in
that case, the compiler will still emit a specific line for the
instruction block that does the assignment. So the actual linetable
will look like this:

    Line 3: prologue
    Line 4. assign j
    Lin3 3. prologue
    Line 5. call sin, assign f
    ...

In that case, the skipping will only skip the first part of the
prologue, and you can still break on any assignment if you'd like.
My patches do not affect that situation either.

> If we can somehow ascertain ourselves that indeed we can still put a
> breakpoint on the second assignment and have it break before entering
> sin(), I think Joels origional diff is actually acceptable.

Hopefully the explaination above convinces you that this is the case?

-- 
Joel

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Michael Snyder <msnyder@specifix.com>, gdb-patches@sourceware.org
> Date: Thu, 10 Jan 2008 10:29:31 +0100
> 
> Joel Brobecker <brobecker@adacore.com> writes:
> 
> > A question that I asked myself was: Why does "break FUNCTION_NAME"
> > skip the prologue and yet "break FILE:LINENO" (from clicking on the
> > filename) doesn't?
> 
> That looks quite natural to me.  If I request a breakpoint on a line I
> want it to be placed as close as possible to that line.  If I request a
> breakpoint on a function, I want it to be set to the first interesting
> point in that function.

Agreed.

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

[Eli Zaretskii]

> Date: Thu, 10 Jan 2008 10:51:03 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: brobecker@adacore.com, msnyder@specifix.com, gdb-patches@sourceware.org
> 
> > IMHO adding knobs is not desirable, but if the default is to keep the
> > current behaviour, I won't object.
> 
> I also would prefer not to add a knob for this.  I don't like knobs
> for things that (IMHO) we should simply decide consistently.

There's nothing wrong with a knob, IMO, when there's controversy about
what's ``consistent''.

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

[Mark Kettenis]

> Date: Thu, 10 Jan 2008 21:35:47 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> 
> The situation becomes trickier at -O1 and beyond, because parts of
> the prologue may be delayed later inside the function body. But in
> that case, the compiler will still emit a specific line for the
> instruction block that does the assignment. So the actual linetable
> will look like this:
> 
>     Line 3: prologue
>     Line 4. assign j
>     Lin3 3. prologue
>     Line 5. call sin, assign f
>     ...
> 
> In that case, the skipping will only skip the first part of the
> prologue, and you can still break on any assignment if you'd like.
> My patches do not affect that situation either.
> 
> > If we can somehow ascertain ourselves that indeed we can still put a
> > breakpoint on the second assignment and have it break before entering
> > sin(), I think Joels origional diff is actually acceptable.
> 
> Hopefully the explaination above convinces you that this is the case?

Thanks Joel, yes, after this explanation, I withdraw my objections.
It's now clear that changing things the way you propose will not
restrict me in any way.

Mark

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

[Joel Brobecker]

> Thanks Joel, yes, after this explanation, I withdraw my objections.
> It's now clear that changing things the way you propose will not
> restrict me in any way.

Yay! :). I am actually very grateful to everyone who participated
in the discussion.

Andreas, Eli, have your concerns been answered too? Just to recap,
the proposal is the following. Considering the following code:

   1.  int
   2.  my_procedure (...)
   3.  {
   4.    int local1 = ...;
   5.    int local2 = ...;
   6.    ...

The idea is that inserting a breakpoint on line 2 or 3 would be
equivalent to breaking on "my_procedure", which means that the
actual location will be line 4 (before the locals assignment
take place).

Thanks,
-- 
Joel

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

[Michael Snyder]

On Thu, 2008-01-10 at 21:35 -0800, Joel Brobecker wrote:
> >   1.  int
> >   2.  foo (int i, double d)
> >   3.  {
> >   4.    int j = 42;
> >   5.    float f = sin(d);
> >   6.    ...
> >   7.  }
> > 
> > the first assignment may be scheduled into the prologue, but the
> > second almost certainly won't.
> 
> The prologue should never include any of the local variable assignments.
> 
> At -O0, the situation is very clear and easy, as the variable
> assignments are always past the prologue. Each variable assignment
> has its own line and you can break on them as usual. My patches
> will not affect that.

Are you sure that's true in general, on all architectures?
I can certainly remember seeing assignment instructions
intermixed with prologue instructions in the past, but I
can't say at what optimization level or on what architecture.

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

[Eric Botcazou]

> Are you sure that's true in general, on all architectures?
> I can certainly remember seeing assignment instructions
> intermixed with prologue instructions in the past, but I
> can't say at what optimization level or on what architecture.

Assignment instructions, sure, but not variable assignments.

-- 
Eric Botcazou

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

[Eli Zaretskii]

> Date: Fri, 11 Jan 2008 10:21:36 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> Andreas, Eli, have your concerns been answered too? Just to recap,
> the proposal is the following. Considering the following code:
> 
>    1.  int
>    2.  my_procedure (...)
>    3.  {
>    4.    int local1 = ...;
>    5.    int local2 = ...;
>    6.    ...
> 
> The idea is that inserting a breakpoint on line 2 or 3 would be
> equivalent to breaking on "my_procedure", which means that the
> actual location will be line 4 (before the locals assignment
> take place).

Actually, I didn't have concern regarding your original patch, but now
that Mark raised the issue, I'm not sure what about his concerns.
Suppose I do want to step through the function prolog -- how would I
accomplish that after your changes?

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

[Mark Kettenis]

> Date: Fri, 11 Jan 2008 23:07:13 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Fri, 11 Jan 2008 10:21:36 -0800
> > From: Joel Brobecker <brobecker@adacore.com>
> > Cc: gdb-patches@sourceware.org
> > 
> > Andreas, Eli, have your concerns been answered too? Just to recap,
> > the proposal is the following. Considering the following code:
> > 
> >    1.  int
> >    2.  my_procedure (...)
> >    3.  {
> >    4.    int local1 = ...;
> >    5.    int local2 = ...;
> >    6.    ...
> > 
> > The idea is that inserting a breakpoint on line 2 or 3 would be
> > equivalent to breaking on "my_procedure", which means that the
> > actual location will be line 4 (before the locals assignment
> > take place).
> 
> Actually, I didn't have concern regarding your original patch, but now
> that Mark raised the issue, I'm not sure what about his concerns.
> Suppose I do want to step through the function prolog -- how would I
> accomplish that after your changes?

Like you always did: break *my_procedure

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

[Eli Zaretskii]

> Date: Fri, 11 Jan 2008 22:13:49 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: brobecker@adacore.com, schwab@suse.de, gdb-patches@sourceware.org
> 
> > Suppose I do want to step through the function prolog -- how would I
> > accomplish that after your changes?
> 
> Like you always did: break *my_procedure

In that case, I think we will need an appropriate change for the
manual as well, as right now, "break *my_procedure" and "break 2" are
equivalent (at least AFAIK).  The manual says:

    `break FUNCTION'
	 Set a breakpoint at entry to function FUNCTION.  When using source
	 languages that permit overloading of symbols, such as C++,
	 FUNCTION may refer to more than one possible place to break.
	 *Note Breakpoint Menus: Breakpoint Menus, for a discussion of that
	 situation.

This doesn't say anything about function prologs.

    `break *ADDRESS'
	 Set a breakpoint at address ADDRESS.  You can use this to set
	 breakpoints in parts of your program which do not have debugging
	 information or source files.

This doesn't say anything about the possible distinction between
*my_procedure as the address and 2 as its source line number.

Am I missing something?

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

[Eli Zaretskii]

> Date: Fri, 11 Jan 2008 22:13:49 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: brobecker@adacore.com, schwab@suse.de, gdb-patches@sourceware.org
> 
> Like you always did: break *my_procedure

Btw, we have quite a few commands that accept addresses as argument,
but the manual never explicitly tells what is a valid address
specification, except piece by piece spread between the individual
commands.

Unless I'm missing something, I'd like to add a node with an
exhaustive definition of an address (or LINESPEC), and then add
cross-references to that place whenever we talk about addresses.  Does
the below list all the possible use cases?

   . LINENO
   . FILENAME:LINENO
   . FUNCTION
   . FILENAME:FUNCTION
   . +OFFSET
   . -OFFSET
   . *FUNCTION
   . *FILENAME:FUNCTION
   . *EXPRESSION

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

[Joel Brobecker]

> In that case, I think we will need an appropriate change for the
> manual as well, as right now, "break *my_procedure" and "break 2" are
> equivalent (at least AFAIK).

I agree and that was in my plans (I believe that any change of behavior
deserves an associated documentation update). I am also planning on
adding a NEWS entry as well.

>     `break FUNCTION'
> 	 Set a breakpoint at entry to function FUNCTION.  When using source
> 	 languages that permit overloading of symbols, such as C++,
> 	 FUNCTION may refer to more than one possible place to break.
> 	 *Note Breakpoint Menus: Breakpoint Menus, for a discussion of that
> 	 situation.
> 
> This doesn't say anything about function prologs.
> 
>     `break *ADDRESS'
> 	 Set a breakpoint at address ADDRESS.  You can use this to set
> 	 breakpoints in parts of your program which do not have debugging
> 	 information or source files.
> 
> This doesn't say anything about the possible distinction between
> *my_procedure as the address and 2 as its source line number.

I think that this is because function prologues are, in the typical
users view, an implementation detail. It's not a concept of the
language, it's more an ABI-related concept. Dare I say that a lot
of engineers nowdays don't know what an ABI is?... (I'll admit that
I learnt about this after I completed my training)

I don't know exactly how to document this behavior change yet, but
I think we need to be careful not to confuse the average joe-hacker
by being too technical too soon.

-- 
Joel

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

[Joel Brobecker]

Hi Eli,

I agree the idea of having a dedicated node for location expressions
is a good idea.

>    . LINENO
>    . FILENAME:LINENO
>    . FUNCTION
>    . FILENAME:FUNCTION
>    . +OFFSET
>    . -OFFSET
>    . *FUNCTION
>    . *FILENAME:FUNCTION
>    . *EXPRESSION

The list looks complete to me.

-- 
Joel

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

[Mark Kettenis]

> Date: Sat, 12 Jan 2008 14:25:24 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> Unless I'm missing something, I'd like to add a node with an
> exhaustive definition of an address (or LINESPEC), and then add
> cross-references to that place whenever we talk about addresses.  Does
> the below list all the possible use cases?
> 
>    . LINENO
>    . FILENAME:LINENO
>    . FUNCTION
>    . FILENAME:FUNCTION
>    . +OFFSET
>    . -OFFSET
>    . *FUNCTION
>    . *FILENAME:FUNCTION
>    . *EXPRESSION

*FUNCTION and *FILENAME:FUNCTION are just special cases of *EXPRESSION

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

[Eli Zaretskii]

> Date: Sat, 12 Jan 2008 16:31:32 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: gdb-patches@sourceware.org
> 
> *FUNCTION and *FILENAME:FUNCTION are just special cases of *EXPRESSION

"*FUNCTION" is generally not a useful C expression, unless FUNCTION
returns a pointer.  So I don't want to rely on the user to guess this
magic in GDB.

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

[Joel Brobecker]

> > *FUNCTION and *FILENAME:FUNCTION are just special cases of *EXPRESSION
> 
> "*FUNCTION" is generally not a useful C expression, unless FUNCTION
> returns a pointer.  So I don't want to rely on the user to guess this
> magic in GDB.

Actually, FUNCTION is a degenerated form of EXPRESSION, and the result
depends on the language. In C, FUNCTION refers to the function pointer
whereas "FUNCTION ()" refers to the return value from a call to FUNCTION.
So, in C, *FUNCTION is the first instruction of our function. However,
in Ada, calls to parameterless function are made by just using the name
of that function. For instance:

        A := Get_A;

So the, when you say "break *FUNCTION", then GDB will first call
FUNCTION, and break at the value returned by that function. So you
have to use "break *FUNCTION'Address", or more simply "break 
*&FUNCTION" should work.

But I still agree that it would be useful to describe the special
case *FUNCTION, as it is a very useful idiom.

-- 
Joel

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

[Mark Kettenis]

> Date: Sat, 12 Jan 2008 17:55:13 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 12 Jan 2008 16:31:32 +0100 (CET)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: gdb-patches@sourceware.org
> > 
> > *FUNCTION and *FILENAME:FUNCTION are just special cases of *EXPRESSION
> 
> "*FUNCTION" is generally not a useful C expression, unless FUNCTION
> returns a pointer.  So I don't want to rely on the user to guess this
> magic in GDB.

Actually *FUNCTION is a perfectly valid C expression, unlike for
example the case where EXPRESSION isn't a pointer like in *0x12345678.

I have no objection to explicitly listing *FUNCTION as a specific
example of *EXPRESSION, but putting it in a whole different class is
misleading IMHO.

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

[Eli Zaretskii]

> Date: Sat, 12 Jan 2008 08:02:33 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb-patches@sourceware.org
> 
> So, in C, *FUNCTION is the first instruction of our function. However,
> in Ada, calls to parameterless function are made by just using the name
> of that function. For instance:
> 
>         A := Get_A;
> 
> So the, when you say "break *FUNCTION", then GDB will first call
> FUNCTION, and break at the value returned by that function. So you
> have to use "break *FUNCTION'Address", or more simply "break 
> *&FUNCTION" should work.

Sorry, I'm not sure I follow: are you saying that "break *Get_A" will
not work when you debug an Ada program?

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

[Eli Zaretskii]

> Date: Sat, 12 Jan 2008 17:18:03 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: gdb-patches@sourceware.org
> 
> > "*FUNCTION" is generally not a useful C expression, unless FUNCTION
> > returns a pointer.  So I don't want to rely on the user to guess this
> > magic in GDB.
> 
> Actually *FUNCTION is a perfectly valid C expression

I didn't say it's invalid; I said it was not useful.  That is, a
casual C programmer is unlikely to think about such an expression.

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

[Daniel Jacobowitz]

On Sat, Jan 12, 2008 at 06:57:39PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 12 Jan 2008 17:18:03 +0100 (CET)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: gdb-patches@sourceware.org
> > 
> > > "*FUNCTION" is generally not a useful C expression, unless FUNCTION
> > > returns a pointer.  So I don't want to rely on the user to guess this
> > > magic in GDB.
> > 
> > Actually *FUNCTION is a perfectly valid C expression
> 
> I didn't say it's invalid; I said it was not useful.  That is, a
> casual C programmer is unlikely to think about such an expression.

I suggest you not think of *FUNCTION as dereferencing FUNCTION.
That's not what the * means here.  * means "what follows is an
expression in the current language; evaluate it as an address and
break there".  In C, a function evaluates to its address (technically,
decays to a function pointer).  The * is not part of the expression.

In Ada, as Joel said, this is not true.  *FUNCTION won't work, because
the * means "an expression follows" and the name of a function taking
no arguments means to call the function.  The * is language
independent in this context.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

> Date: Sat, 12 Jan 2008 12:58:17 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb-patches@sourceware.org
> 
> On Sat, Jan 12, 2008 at 06:57:39PM +0200, Eli Zaretskii wrote:
> > > Date: Sat, 12 Jan 2008 17:18:03 +0100 (CET)
> > > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > > CC: gdb-patches@sourceware.org
> > > 
> > > > "*FUNCTION" is generally not a useful C expression, unless FUNCTION
> > > > returns a pointer.  So I don't want to rely on the user to guess this
> > > > magic in GDB.
> > > 
> > > Actually *FUNCTION is a perfectly valid C expression
> > 
> > I didn't say it's invalid; I said it was not useful.  That is, a
> > casual C programmer is unlikely to think about such an expression.
> 
> I suggest you not think of *FUNCTION as dereferencing FUNCTION.
> That's not what the * means here.  * means "what follows is an
> expression in the current language; evaluate it as an address and
> break there".  In C, a function evaluates to its address (technically,
> decays to a function pointer).  The * is not part of the expression.

Sigh.  This must be one of those days when I'm unable to explain
myself.

Look, I didn't say _I_ didn't know about *FUNCTION, so you don't need
to explain that to _me_.  I said it is generally not used in programs.
Therefore, its use in GDB is unintuitive given just programming
experience.

> In Ada, as Joel said, this is not true.  *FUNCTION won't work

That's too bad: this is an important feature, so if we cannot make it
work in all languages, we should at least document that.

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

[Joel Brobecker]

> > In Ada, as Joel said, this is not true.  *FUNCTION won't work
> 
> That's too bad: this is an important feature, so if we cannot make it
> work in all languages, we should at least document that.

What I suggest is that we document *FUNCTION as a special case and yet
very useful form of *EXPRESSION, and explain why it works. We can then
mention that this doesn't work as-is in Ada, and see how the same
principle can be adapted for this language.

-- 
Joel

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

[Eli Zaretskii]

> Date: Sat, 12 Jan 2008 22:24:50 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Daniel Jacobowitz <drow@false.org>, mark.kettenis@xs4all.nl,
> 	gdb-patches@sourceware.org
> 
> > > In Ada, as Joel said, this is not true.  *FUNCTION won't work
> > 
> > That's too bad: this is an important feature, so if we cannot make it
> > work in all languages, we should at least document that.
> 
> What I suggest is that we document *FUNCTION as a special case and yet
> very useful form of *EXPRESSION, and explain why it works.

In what languages _does_ it work, besides C/C++?

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

[Mark Kettenis]

> Date: Sun, 13 Jan 2008 06:21:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > In Ada, as Joel said, this is not true.  *FUNCTION won't work
> 
> That's too bad: this is an important feature, so if we cannot make it
> work in all languages, we should at least document that.

This is exactly the reason why documenting *FUNCTION on its own is the
wrong thing to do.  What we implement in GDB is *EXPRESSION, where
EXPRESSION is an expression in the current language yielding an
address.  For C FUNCTION will do as an expression; &FUNCTION will do
as well.  Function pointers are a pretty standard feature of the C
language, so I expect users to know about them.

For Ada the appropriate expression is FUNCTION'Address or &FUNCTION.
Other languages might also need a different syntax; I doubt &FUNCTION
will work in Pascal or FORTRAN.

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

[Eli Zaretskii]

> Date: Sun, 13 Jan 2008 10:21:13 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: drow@false.org, mark.kettenis@xs4all.nl, gdb-patches@sourceware.org
> 
> > Date: Sun, 13 Jan 2008 06:21:36 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > In Ada, as Joel said, this is not true.  *FUNCTION won't work
> > 
> > That's too bad: this is an important feature, so if we cannot make it
> > work in all languages, we should at least document that.
> 
> This is exactly the reason why documenting *FUNCTION on its own is the
> wrong thing to do.  What we implement in GDB is *EXPRESSION, where
> EXPRESSION is an expression in the current language yielding an
> address.

You seem to be saying that documenting things that might be obvious is
a bad thing.  If so, then I disagree: if it wasn't obvious for me,
there will be others.

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

[Joel Brobecker]

> > What I suggest is that we document *FUNCTION as a special case and yet
> > very useful form of *EXPRESSION, and explain why it works.
> 
> In what languages _does_ it work, besides C/C++?

I can say for sure for some of the languages only. For sure, it will
work with c, c++, asm, minimal, objective-c. I made some experiments
by forcing the language to other values, and tried "break *main",
and it also worked for the following languages: fortran, java,
modula-2, and pascal. It did NOT work with scheme. We have users
from at least Fortran, Pascal and Modula-2, we should as them to
confirm.

-- 
Joel

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

[Pierre Muller]

  I just tested &win32_close
and it does not work....
I get 
Function "" not defined.
Make breakpoint pending ...

  If you use pascal language,
the construct '*win32_close' still works, but this is
mainly because I left the
'*' prefix operator in the pascal parser, even though it is not
real pascal syntax.

The address prefix is '@' in pascal, but trying it out gives the 
same as '&' operator in C.

  Anyhow, win32_close is already a memory address, so
what should the address of an address mean?

Pierre Muller
gdb pascal language support maintainer.


> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Mark Kettenis
> Sent: Sunday, January 13, 2008 10:21 AM
> To: eliz@gnu.org
> Cc: drow@false.org; mark.kettenis@xs4all.nl; gdb-patches@sourceware.org
> Subject: Re: [RFC/RFA?] Should break FILE:LINENO skip prologue?
> 
> > Date: Sun, 13 Jan 2008 06:21:36 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > > In Ada, as Joel said, this is not true.  *FUNCTION won't work
> >
> > That's too bad: this is an important feature, so if we cannot make it
> > work in all languages, we should at least document that.
> 
> This is exactly the reason why documenting *FUNCTION on its own is the
> wrong thing to do.  What we implement in GDB is *EXPRESSION, where
> EXPRESSION is an expression in the current language yielding an
> address.  For C FUNCTION will do as an expression; &FUNCTION will do
> as well.  Function pointers are a pretty standard feature of the C
> language, so I expect users to know about them.
> 
> For Ada the appropriate expression is FUNCTION'Address or &FUNCTION.
> Other languages might also need a different syntax; I doubt &FUNCTION
> will work in Pascal or FORTRAN.

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

[Daniel Jacobowitz]

On Mon, Jan 14, 2008 at 11:30:05AM +0100, Pierre Muller wrote:
>   I just tested &win32_close
> and it does not work....
> I get 
> Function "" not defined.
> Make breakpoint pending ...

It would be "break *&win32_close".  Did you try that?  The * is
not part of the expression - it just means that an expression follows.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Jim Blandy]

Eli Zaretskii <eliz at gnu.org> writes:
> I said it is generally not used in programs.
> Therefore, its use in GDB is unintuitive given just programming
> experience.

It is almost as widely used as function pointers.  In my experience
(including code outside GDB), it's the preferred way to get a function
pointer.

I think the GDB manual should document '*EXPRESSION', and then mention
the useful special case that in C, '*FUNCTION' refers to the first
instruction in FUNCTION, before the stack frame and arguments have
been set up.

I suspect less technical readers will assume that the term 'entry
point' simply means the point at which none of the function's body
statements have executed yet.  It will not suggest to them that the
stack and arguments may be in an odd state.  So if the manual
describes 'break *FUNCTION' as a way to set a breakpoint "at
FUNCTION's entry point", I think many users will use it when they
would be happier with 'break FUNCTION'.  So I think the documentation
for the '*FUNCTION' special case should spell out what that means,
perhaps with a phrase like the one I used in the paragraph before this
one.

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

[Jim Blandy]

Eli Zaretskii <eliz at gnu.org> writes:
>> Date: Sun, 13 Jan 2008 10:21:13 +0100 (CET)
>> From: Mark Kettenis <mark.kettenis@xs4all.nl>
>> CC: drow@false.org, mark.kettenis@xs4all.nl, gdb-patches@sourceware.org
>> 
>> > Date: Sun, 13 Jan 2008 06:21:36 +0200
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > 
>> > > In Ada, as Joel said, this is not true.  *FUNCTION won't work
>> > 
>> > That's too bad: this is an important feature, so if we cannot make it
>> > work in all languages, we should at least document that.
>> 
>> This is exactly the reason why documenting *FUNCTION on its own is the
>> wrong thing to do.  What we implement in GDB is *EXPRESSION, where
>> EXPRESSION is an expression in the current language yielding an
>> address.
>
> You seem to be saying that documenting things that might be obvious is
> a bad thing.  If so, then I disagree: if it wasn't obvious for me,
> there will be others.

There are three possible approaches:

a) In Eli's original message, the list include "*EXPRESSION" and
   "*FUNCTION" as separate cases.  This suggested to me that Eli
   thought we should document them as separate cases.

b) We could document the "*EXPRESSION" case, and then point out the
   commonly used "*FUNCTION" usage of that case.

c) We could document "*EXPRESSION", and not mention "*FUNCTION" at
   all.

I dislike a), because it suggests that "*FUNCTION" is recognized
specially --- it is not.  In many languages this doesn't matter, but
as Joel points out, a) would be actively misleading for Ada users, as
"*FUNCTION" does not refer to the first instruction of FUNCTION in
Ada.

I dislike c), for the reasons Eli mentioned, and because I appreciate
having handy use cases pointed out.

So b) is my first choice.

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

[Mark Kettenis]

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Mon, 14 Jan 2008 14:24:55 -0800
> 
> There are three possible approaches:
> 
> a) In Eli's original message, the list include "*EXPRESSION" and
>    "*FUNCTION" as separate cases.  This suggested to me that Eli
>    thought we should document them as separate cases.
> 
> b) We could document the "*EXPRESSION" case, and then point out the
>    commonly used "*FUNCTION" usage of that case.
> 
> c) We could document "*EXPRESSION", and not mention "*FUNCTION" at
>    all.
> 
> I dislike a), because it suggests that "*FUNCTION" is recognized
> specially --- it is not.  In many languages this doesn't matter, but
> as Joel points out, a) would be actively misleading for Ada users, as
> "*FUNCTION" does not refer to the first instruction of FUNCTION in
> Ada.
> 
> I dislike c), for the reasons Eli mentioned, and because I appreciate
> having handy use cases pointed out.
> 
> So b) is my first choice.

And b) is exactly what I tried to get across (although it seems I
failed).  Hopefully this mail from Jim clarifies things.

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

[Michael Snyder]

On Sat, 2008-01-12 at 16:31 +0100, Mark Kettenis wrote:
> > Date: Sat, 12 Jan 2008 14:25:24 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > Unless I'm missing something, I'd like to add a node with an
> > exhaustive definition of an address (or LINESPEC), and then add
> > cross-references to that place whenever we talk about addresses.  Does
> > the below list all the possible use cases?
> > 
> >    . LINENO
> >    . FILENAME:LINENO
> >    . FUNCTION
> >    . FILENAME:FUNCTION
> >    . +OFFSET
> >    . -OFFSET
> >    . *FUNCTION
> >    . *FILENAME:FUNCTION
> >    . *EXPRESSION
> 
> *FUNCTION and *FILENAME:FUNCTION are just special cases of *EXPRESSION

But important extensions, as they are not part of the target language.

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

[Michael Snyder]

On Sun, 2008-01-13 at 01:54 -0500, Eli Zaretskii wrote:
> > Date: Sat, 12 Jan 2008 22:24:50 -0800
> > From: Joel Brobecker <brobecker@adacore.com>
> > Cc: Daniel Jacobowitz <drow@false.org>, mark.kettenis@xs4all.nl,
> > 	gdb-patches@sourceware.org
> > 
> > > > In Ada, as Joel said, this is not true.  *FUNCTION won't work
> > > 
> > > That's too bad: this is an important feature, so if we cannot make it
> > > work in all languages, we should at least document that.
> > 
> > What I suggest is that we document *FUNCTION as a special case and yet
> > very useful form of *EXPRESSION, and explain why it works.
> 
> In what languages _does_ it work, besides C/C++?

Speaking from memory, and therefore this may not be the 
way it works today...

break *expression used to be a special case of the
break command, and NOT the same as "break (*expression).
The * in this case is (was) NOT treated as the * expression op.
It meant "treat the following expression as a literal address,
and PUT A BREAKPOINT THERE (as opposed to skipping a prologue
first and then putting a breakpoint).  It did NOT mean "dereference
a pointer expression".

This is a fallout of the fact that the argument to the break
command is not simply an expression --  an expression is just
one of several possibilities.  The "*" is a disambiguator, 
albeit perhaps a poorly chosen one.  It means, "this is not
an expression, this is a linespec, something that evaluates
to an address, and I don't want any post-processing done
to the address (such as skip-prologue).

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

[Michael Snyder]

On Sun, 2008-01-13 at 10:21 +0100, Mark Kettenis wrote:
> > Date: Sun, 13 Jan 2008 06:21:36 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > In Ada, as Joel said, this is not true.  *FUNCTION won't work
> > 
> > That's too bad: this is an important feature, so if we cannot make it
> > work in all languages, we should at least document that.
> 
> This is exactly the reason why documenting *FUNCTION on its own is the
> wrong thing to do.  What we implement in GDB is *EXPRESSION, where
> EXPRESSION is an expression in the current language yielding an
> address. 

Mark, I don't think that is true -- at least it used to be not
(damn English language...)

When you say "break *<something>", the asterisk is NOT 
interpreted by the expression parser -- it is interpreted
by the break command, or more precisely, by the LINESPEC
parser.

It is (or used to be) a part of the LINESPEC syntax, 
not a part of the expression syntax.  It simply happens
to be ambiguous with the expression operator "unary *".

As a LINESPEC operator, it means "evaluate what follows
and treat it as a literal address, without doing
skip-prologue processing on it.

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

[Michael Snyder]

On Sun, 2008-01-13 at 02:36 -0800, Joel Brobecker wrote:
> > > What I suggest is that we document *FUNCTION as a special case and yet
> > > very useful form of *EXPRESSION, and explain why it works.
> > 
> > In what languages _does_ it work, besides C/C++?
> 
> I can say for sure for some of the languages only. For sure, it will
> work with c, c++, asm, minimal, objective-c. I made some experiments
> by forcing the language to other values, and tried "break *main",
> and it also worked for the following languages: fortran, java,
> modula-2, and pascal. It did NOT work with scheme. We have users
> from at least Fortran, Pascal and Modula-2, we should as them to
> confirm.

Joel, if my memory is correct, this is because the "*" is not
interpreted by the language parser, it is interpreted by the
linespec parser.

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

[Joel Brobecker]

Hi Michael,

> Joel, if my memory is correct, this is because the "*" is not
> interpreted by the language parser, it is interpreted by the
> linespec parser.

Right. In my mind, the issue was not with the "*", but in determining
for each language if the expression "FUNCTION_NAME" returned the
function address or not. It looks like it is the case for most
languages supported by GDB. The only exceptions apparently are
Ada and SCM.

-- 
Joel

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

[Daniel Jacobowitz]

On Mon, Jan 14, 2008 at 02:49:39PM -0800, Michael Snyder wrote:
> > >    . *FILENAME:FUNCTION
> > >    . *EXPRESSION
> > 
> > *FUNCTION and *FILENAME:FUNCTION are just special cases of *EXPRESSION
> 
> But important extensions, as they are not part of the target language.

By the way, has anyone tried *FILENAME:FUNCTION?  I'm surprised that
works, since it would have to be part of the C parser.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> 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.

-- 
Joel

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

[Jim Blandy]

Michael Snyder <msnyder at specifix.com> writes:
> On Sun, 2008-01-13 at 10:21 +0100, Mark Kettenis wrote:
>> > Date: Sun, 13 Jan 2008 06:21:36 +0200
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > 
>> > > In Ada, as Joel said, this is not true.  *FUNCTION won't work
>> > 
>> > That's too bad: this is an important feature, so if we cannot make it
>> > work in all languages, we should at least document that.
>> 
>> This is exactly the reason why documenting *FUNCTION on its own is the
>> wrong thing to do.  What we implement in GDB is *EXPRESSION, where
>> EXPRESSION is an expression in the current language yielding an
>> address. 
>
> Mark, I don't think that is true -- at least it used to be not
> (damn English language...)
>
> When you say "break *<something>", the asterisk is NOT 
> interpreted by the expression parser -- it is interpreted
> by the break command, or more precisely, by the LINESPEC
> parser.

Mark is agreeing with you.  He said the syntax is:

    break *EXPRESSION

Since the * is written out explicitly, it is not part of EXPRESSION.
If Mark had wanted to indicate that the expression parser was handling
that *, he would have written

    break EXPRESSION

We're all in violent agreement that this isn't what GDB does at
present.  :) From decode_line_1:

  /* See if arg is *PC.  */

  if (**argptr == '*')
    return decode_indirect (argptr);

where:

  /* Decode arg of the form *PC.  */

  static struct symtabs_and_lines
  decode_indirect (char **argptr)
  {
    struct symtabs_and_lines values;
    CORE_ADDR pc;

    (*argptr)++;
    pc = parse_and_eval_address_1 (argptr);

    ...
  }

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

[Jim Blandy]

Joel Brobecker <brobecker at adacore.com> writes:
>> 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.

I sure hope nobody else is reading this thread.  :)

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

[Eli Zaretskii]

> 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.

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

[Ulrich Weigand]

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

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

[Andreas Schwab]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:

> 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).

Note that the value of FUNCTION is even target dependent.  On ppc64
ordinary function symbols point to function descriptors, whereas code
addresses have symbols that start with a '.'.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Michael Snyder]

On Tue, 2008-01-15 at 07:29 -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 14, 2008 at 02:49:39PM -0800, Michael Snyder wrote:
> > > >    . *FILENAME:FUNCTION
> > > >    . *EXPRESSION
> > > 
> > > *FUNCTION and *FILENAME:FUNCTION are just special cases of *EXPRESSION
> > 
> > But important extensions, as they are not part of the target language.
> 
> By the way, has anyone tried *FILENAME:FUNCTION?  I'm surprised that
> works, since it would have to be part of the C parser.

No -- it would have to be part of the LINESPEC parser.

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

[Eli Zaretskii]

> 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
> 

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

[Eli Zaretskii]

> 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*.

You are talking from the GDB code point of views, while I'm talking
from the user point of view.

Btw, the manual does not say *EXPRESSION, it says *ADDRESS.

Anyway, if "break *FILENAME:FUNCTION" does not need to work, then how
does one set a breakpoint on the entry point of FILENAME:FUNCTION,
after the suggested change that makes "break FUNCTION" behave
differently than "break *FUNCTION"?

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: eliz@gnu.org, brobecker@adacore.com (Joel Brobecker),
> 	msnyder@specifix.com, mark.kettenis@xs4all.nl,
> 	gdb-patches@sourceware.org
> Date: Wed, 16 Jan 2008 00:23:45 +0100
> 
> "Ulrich Weigand" <uweigand@de.ibm.com> writes:
> 
> > 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).
> 
> Note that the value of FUNCTION is even target dependent.  On ppc64
> ordinary function symbols point to function descriptors, whereas code
> addresses have symbols that start with a '.'.

Are you saying that "break *FUNCTION" will not work on a ppc64, even
in a C program?

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

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: eliz@gnu.org, brobecker@adacore.com (Joel Brobecker),
>> 	msnyder@specifix.com, mark.kettenis@xs4all.nl,
>> 	gdb-patches@sourceware.org
>> Date: Wed, 16 Jan 2008 00:23:45 +0100
>> 
>> "Ulrich Weigand" <uweigand@de.ibm.com> writes:
>> 
>> > 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).
>> 
>> Note that the value of FUNCTION is even target dependent.  On ppc64
>> ordinary function symbols point to function descriptors, whereas code
>> addresses have symbols that start with a '.'.
>
> Are you saying that "break *FUNCTION" will not work on a ppc64, even
> in a C program?

It works if you use the correct symbol.  In the absence of debug
information the non-dot symbol will give the wrong result.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Mark Kettenis]

> Date: Wed, 16 Jan 2008 06:20:29 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > 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*.
> 
> You are talking from the GDB code point of views, while I'm talking
> from the user point of view.
> 
> Btw, the manual does not say *EXPRESSION, it says *ADDRESS.

That's fine as long as the manual says that ADDRESS is parsed as an
expression in the current language.  Probably writing *ADDRESS in the
manual is better since it makes clear that whatever follows the '*' is
interpreted as an address.

> Anyway, if "break *FILENAME:FUNCTION" does not need to work, then how
> does one set a breakpoint on the entry point of FILENAME:FUNCTION,
> after the suggested change that makes "break FUNCTION" behave
> differently than "break *FUNCTION"?

Joel's change does not change how "break FUNCTION" works at all.  It
changes what "break LINE" does in the case where LINE doesn't
correspond to an actual line of source code, and makes it more similar
to what "break FUNCTION" does, which is putting the breakpoint on the
first line of actual code in a function.

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: uweigand@de.ibm.com, brobecker@adacore.com, msnyder@specifix.com,
> 	mark.kettenis@xs4all.nl, gdb-patches@sourceware.org
> Date: Wed, 16 Jan 2008 10:13:28 +0100
> 
> >> Note that the value of FUNCTION is even target dependent.  On ppc64
> >> ordinary function symbols point to function descriptors, whereas code
> >> addresses have symbols that start with a '.'.
> >
> > Are you saying that "break *FUNCTION" will not work on a ppc64, even
> > in a C program?
> 
> It works if you use the correct symbol.  In the absence of debug
> information the non-dot symbol will give the wrong result.

Can you give an example?  I'm not sure I'm following you.  E.g., will
"break *main" work in a C program?

Or are you talking only about the case of missing debug info?

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

[Eli Zaretskii]

> Date: Wed, 16 Jan 2008 11:34:41 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: uweigand@de.ibm.com, brobecker@adacore.com, msnyder@specifix.com,
>         gdb-patches@sourceware.org
> 
> > Btw, the manual does not say *EXPRESSION, it says *ADDRESS.
> 
> That's fine as long as the manual says that ADDRESS is parsed as an
> expression in the current language.

It doesn't.  It says it "may be any expression", which is vague, even
inaccurate.

> > Anyway, if "break *FILENAME:FUNCTION" does not need to work, then how
> > does one set a breakpoint on the entry point of FILENAME:FUNCTION,
> > after the suggested change that makes "break FUNCTION" behave
> > differently than "break *FUNCTION"?
> 
> Joel's change does not change how "break FUNCTION" works at all.  It
> changes what "break LINE" does in the case where LINE doesn't
> correspond to an actual line of source code, and makes it more similar
> to what "break FUNCTION" does, which is putting the breakpoint on the
> first line of actual code in a function.

My question was about putting the breakpoint on the beginning of the
prolog of a function in another file, not about "break FUNCTION" or
"break LINE".  You didn't answer my question: how does one put a
breakpoint on that address.  For a function in the current file, or
one whose name identifies it unambiguously, "break *FUNCTION" is the
solution.  But what about the case where FUNCTION alone is not enough
to unambiguously specify a function?

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

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Or are you talking only about the case of missing debug info?

Yes.  For example, if libc has no debug info then printf (which is a
symbol in the .opd section) resolves to the function descriptor address,
and to get the real code address you need to use '._IO_printf'.  The
ppc64 target is pretty unique in this behaviour, on ia64 you don't have
this problem even though it uses function descriptors as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Jim Blandy]

"Ulrich Weigand" <uweigand at de.ibm.com> writes:
> 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*.

I'd like to record my strong agreement with Uli here.  The expectation
that *FILENAME:FUNCTION ought to work is just a confusion that results
from thinking of *FUNCTION as a separate case from *EXPRESSION.
They're not separate: the first is a common application of the second,
in some languages.

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

[Jim Blandy]

Eli Zaretskii <eliz at gnu.org> writes:
>> Date: Wed, 16 Jan 2008 11:34:41 +0100 (CET)
>> From: Mark Kettenis <mark.kettenis@xs4all.nl>
>> CC: uweigand@de.ibm.com, brobecker@adacore.com, msnyder@specifix.com,
>>         gdb-patches@sourceware.org
>> 
>> > Btw, the manual does not say *EXPRESSION, it says *ADDRESS.
>> 
>> That's fine as long as the manual says that ADDRESS is parsed as an
>> expression in the current language.
>
> It doesn't.  It says it "may be any expression", which is vague, even
> inaccurate.
>
>> > Anyway, if "break *FILENAME:FUNCTION" does not need to work, then how
>> > does one set a breakpoint on the entry point of FILENAME:FUNCTION,
>> > after the suggested change that makes "break FUNCTION" behave
>> > differently than "break *FUNCTION"?
>> 
>> Joel's change does not change how "break FUNCTION" works at all.  It
>> changes what "break LINE" does in the case where LINE doesn't
>> correspond to an actual line of source code, and makes it more similar
>> to what "break FUNCTION" does, which is putting the breakpoint on the
>> first line of actual code in a function.
>
> My question was about putting the breakpoint on the beginning of the
> prolog of a function in another file, not about "break FUNCTION" or
> "break LINE".  You didn't answer my question: how does one put a
> breakpoint on that address.  For a function in the current file, or
> one whose name identifies it unambiguously, "break *FUNCTION" is the
> solution.  But what about the case where FUNCTION alone is not enough
> to unambiguously specify a function?

GDB allows 'FILENAME'::FUNCTION in C expressions:

  $ cat u.mk
  CC = gcc
  CFLAGS = -g3
  u: u1.o u2.o
          $(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
  clean:
          rm -f u u1.o u2.o
  $ cat u1.c
  #include <stdio.h>

  void e (void);

  static void
  s (void)
  {
    puts ("u1.c: s");
  }

  int
  main (int argc, char **argv)
  {
    s ();
    e ();

    return 0;
  }
  $ cat u2.c
  #include <stdio.h>

  static void
  s (void)
  {
    puts ("u2.c: s");
  }

  void
  e (void)
  {
    puts ("u2.c: e");
    s ();
  }
  $ make -f u.mk
  gcc -g3   -c -o u1.o u1.c
  gcc -g3   -c -o u2.o u2.c
  gcc  u1.o u2.o  -o u
  $ ~/gdb/pub/nat/gdb/gdb u
  GNU gdb 6.7.50.20080111-cvs
  Copyright (C) 2008 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-pc-linux-gnu"...
  (gdb) print 'u1.c'::s
  $1 = {void (void)} 0x8048384 <s>
  (gdb) print 'u2.c'::s
  $2 = {void (void)} 0x80483c4 <s>
  (gdb) break *'u1.c'::s
  Breakpoint 1 at 0x8048384: file u1.c, line 7.
  (gdb) break *'u2.c'::s
  Breakpoint 2 at 0x80483c4: file u2.c, line 5.
  (gdb) 

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

[Eli Zaretskii]

> 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?

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

[Michael Snyder]

On Thu, 2008-01-17 at 06:13 +0200, Eli Zaretskii wrote:
> > 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?

Right.  It is a separate parser, the LINEINFO parser, as 
opposed to the expression parser.  It defines a superset
of the expression syntax.  It is used mainly by the 'break'
and 'list' commands.

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

[Mark Kettenis]

> From: Michael Snyder <msnyder@specifix.com>
> Date: Wed, 16 Jan 2008 20:18:03 -0800
> 
> On Thu, 2008-01-17 at 06:13 +0200, Eli Zaretskii wrote:
> > > 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?
> 
> Right.  It is a separate parser, the LINEINFO parser, as 
> opposed to the expression parser.  It defines a superset
> of the expression syntax.  It is used mainly by the 'break'
> and 'list' commands.

That isn't quite true.  The LINESPEC (I assume that's what you meant
with LINEINFO) parser only parses the '*' and then hands things off to
the standard expression parser.

This of course is a good thing, because it means expressions are
handled uniformly all over GDB.

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

[Jim Blandy]

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.

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

[Michael Snyder]

On Thu, 2008-01-17 at 10:45 +0100, Mark Kettenis wrote:
> > From: Michael Snyder <msnyder@specifix.com>
> > Date: Wed, 16 Jan 2008 20:18:03 -0800
> > 
> > On Thu, 2008-01-17 at 06:13 +0200, Eli Zaretskii wrote:
> > > > 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?
> > 
> > Right.  It is a separate parser, the LINEINFO parser, as 
> > opposed to the expression parser.  It defines a superset
> > of the expression syntax.  It is used mainly by the 'break'
> > and 'list' commands.
> 
> That isn't quite true.  The LINESPEC (I assume that's what you meant
> with LINEINFO) parser only parses the '*' and then hands things off to
> the standard expression parser.
> 
> This of course is a good thing, because it means expressions are
> handled uniformly all over GDB.

We're on the same page, possibly not the same paragraph.

I'm not looking at the code, just going from memory -- 
but I think the LINESPEC parser used to do a bit more
than just parse the "*".  For instance, it would have to
parse that "::" up there, n'est ce pas? 

Anyway, yes, the LINESPEC parser does call the expression
parser, but it also does some syntax itself, thus generating
a superset of the language-specified expression syntax.
We're all agreed on that much.

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

[Jim Blandy]

Michael Snyder <msnyder at specifix.com> writes:
> On Thu, 2008-01-17 at 10:45 +0100, Mark Kettenis wrote:
>> > From: Michael Snyder <msnyder@specifix.com>
>> > Date: Wed, 16 Jan 2008 20:18:03 -0800
>> > 
>> > On Thu, 2008-01-17 at 06:13 +0200, Eli Zaretskii wrote:
>> > > > 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?
>> > 
>> > Right.  It is a separate parser, the LINEINFO parser, as 
>> > opposed to the expression parser.  It defines a superset
>> > of the expression syntax.  It is used mainly by the 'break'
>> > and 'list' commands.
>> 
>> That isn't quite true.  The LINESPEC (I assume that's what you meant
>> with LINEINFO) parser only parses the '*' and then hands things off to
>> the standard expression parser.
>> 
>> This of course is a good thing, because it means expressions are
>> handled uniformly all over GDB.
>
> We're on the same page, possibly not the same paragraph.
>
> I'm not looking at the code, just going from memory -- 
> but I think the LINESPEC parser used to do a bit more
> than just parse the "*".  For instance, it would have to
> parse that "::" up there, n'est ce pas? 

Actually, :: is actually a GDB extension to the C expression syntax.
If you look at the example interaction in the message at the link, you
can see this in the two 'print' commands, where I use the :: operator.

http://sourceware.org/ml/gdb-patches/2008-01/msg00417.html

> Anyway, yes, the LINESPEC parser does call the expression
> parser, but it also does some syntax itself, thus generating
> a superset of the language-specified expression syntax.
> We're all agreed on that much.

Once it has recognized the '*', linespec.c passes things off directly
to the language expression parser, with no further munging; see the
code fragments I posted here:

    http://sourceware.org/ml/gdb-patches/2008-01/msg00354.html

So, the syntax of things that may appear after the '*' is exactly an
expression, no less or more.

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

[Michael Snyder]

On Thu, 2008-01-17 at 14:08 -0800, Jim Blandy wrote:

> Once it has recognized the '*', linespec.c passes things off directly
> to the language expression parser, with no further munging; see the
> code fragments I posted here:
> 
>     http://sourceware.org/ml/gdb-patches/2008-01/msg00354.html
> 
> So, the syntax of things that may appear after the '*' is exactly an
> expression, no less or more.

I see, so I'm arguing from stale state.
The linespec parser used to do much more than that.
Sounds like an improvement, anyway...

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

[Eli Zaretskii]

> 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.

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

[Joel Brobecker]

Hi Eli,

I think this is a great improvement in terms of clarity. Thanks!


> -@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.

This is actually not true. It's usually the first line of code
past the open brace.

> As a convenience, @value{GDBN} extends the semantics of
> +expressions used in locations to cover the situations that frequently
> +happen during debugging.

I was a little bit confused at first by this sentence, as I thought
that you were saying that all the forms you are describing later are
extensions, which as you explain for C/C++/etc is not the case.
At the same time, I found it pretty hard to try to do better. Perhaps
if we took a different approach and made a subsection that describe
expressions that return the address of a function, and why they are
useful, then maybe we would be able to unconfuse things. For instance:

    Breaking on the first instruction of a function:
    
    Inserting a breakpoint on a function will result as documented at ... in
    a breakpoint at the first line of code inside the body of that function.
    Instead, you might sometimes want to break on the very first instruction
    of that function, inside the function prologue. To do that, you should
    use the *address linespec syntax, where address is an expression valid
    in the current language that returns the address of your function.
    
    All languages provide a way of getting a function address from its name,
    either as a valid expression for that language, or as an extension to
    this language.  Here they are:
    
      - C/C++/etc...: function_name.
      - Pascal and M2: &function_name.
      - Ada: function_name'Address. &function_name can also be used as
        an extension.

Hope this helps :)

-- 
Joel

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

[Eli Zaretskii]

> Date: Sun, 20 Jan 2008 07:02:24 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Jim Blandy <jimb@codesourcery.com>, mark.kettenis@xs4all.nl,
> 	uweigand@de.ibm.com, msnyder@specifix.com,
> 	gdb-patches@sourceware.org
> 
> >  @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.
> 
> This is actually not true. It's usually the first line of code
> past the open brace.

You seem to be thinking about source code formatted according to GNU
coding standards ;-) But C allows code to appear on the same line as
the open brace, so it's not simple to say this with absolute accuracy.
I think on balance, the current wording is not bad: after all, why
should a GDB user care whether the brace itself does or does not
generate executable code?

> > As a convenience, @value{GDBN} extends the semantics of
> > +expressions used in locations to cover the situations that frequently
> > +happen during debugging.
> 
> I was a little bit confused at first by this sentence, as I thought
> that you were saying that all the forms you are describing later are
> extensions, which as you explain for C/C++/etc is not the case.
> At the same time, I found it pretty hard to try to do better.

How about if I say that the extension is in addition to the ``normal''
expression syntax?  Like this:

  Here @var{address} may be any expression valid in the current working
  language (@pxref{Languages, working language}) that specifies a code
  address.  In addition, as a convenience, @value{GDBN} extends the
  semantics of expressions...

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

[Joel Brobecker]

> > > -For example: in C, this is the line with the open brace.
> > > +For example, in C, this is the line with the open brace.
> > 
> > This is actually not true. It's usually the first line of code
> > past the open brace.
> 
> You seem to be thinking about source code formatted according to GNU
> coding standards ;-) But C allows code to appear on the same line as
> the open brace, so it's not simple to say this with absolute accuracy.

I agree that we can't always be accurate.

> I think on balance, the current wording is not bad: after all, why
> should a GDB user care whether the brace itself does or does not
> generate executable code?

I agree that a typical user doesn't care, but I disagree that the
current wording is OK. In the vast majority of the C code that
I have seen, except in one-liner functions, people didn't write code
on the same line as the opening brace. So the sentence will be false
most of the time (in my case).

I suggest we just delete this sentence altogether. Or, maybe what
we can do is use an actual example where we can use the formatting
we want.

> How about if I say that the extension is in addition to the ``normal''
> expression syntax?  Like this:
> 
>   Here @var{address} may be any expression valid in the current working
>   language (@pxref{Languages, working language}) that specifies a code
>   address.  In addition, as a convenience, @value{GDBN} extends the
>   semantics of expressions...

Sure, it is clearer.

-- 
Joel

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

[Eli Zaretskii]

> Date: Sun, 20 Jan 2008 18:27:18 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: jimb@codesourcery.com, mark.kettenis@xs4all.nl, uweigand@de.ibm.com,
> 	msnyder@specifix.com, gdb-patches@sourceware.org
> 
> > How about if I say that the extension is in addition to the ``normal''
> > expression syntax?  Like this:
> > 
> >   Here @var{address} may be any expression valid in the current working
> >   language (@pxref{Languages, working language}) that specifies a code
> >   address.  In addition, as a convenience, @value{GDBN} extends the
> >   semantics of expressions...
> 
> Sure, it is clearer.

I made this change, thanks.

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

[Daniel Jacobowitz]

On Wed, Jan 09, 2008 at 07:17:45AM -0800, Joel Brobecker wrote:
> 2008-01-09  Joel Brobecker  <brobecker@adacore.com>
> 
>         * breakpoint.c (skip_prologue_sal): New function.
>         (resolve_sal_pc): Adjust SAL past prologue if the SAL was
>         computed from a line number.

I tried to reread the thread below this patch, but eventually got
lost.  What was the verdict?

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> > 2008-01-09  Joel Brobecker  <brobecker@adacore.com>
> > 
> >         * breakpoint.c (skip_prologue_sal): New function.
> >         (resolve_sal_pc): Adjust SAL past prologue if the SAL was
> >         computed from a line number.
> 
> I tried to reread the thread below this patch, but eventually got
> lost.  What was the verdict?

Everyone pretty much agreed :).

I should have sent a message earlier, but you've kept me busy with
the other patches I've sent ;-). I'm ready to commit now, but we'll
need to adjust the testsuite at a few places, I think. I can take
care of that either today or tomorrow.

-- 
Joel

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

Hi Daniel,

> > 2008-01-09  Joel Brobecker  <brobecker@adacore.com>
> > 
> >         * breakpoint.c (skip_prologue_sal): New function.
> >         (resolve_sal_pc): Adjust SAL past prologue if the SAL was
> >         computed from a line number.
> 
> I tried to reread the thread below this patch, but eventually got
> lost.  What was the verdict?

As I said yesterday, the idea eventually got accepted by everyone.
Here is the patch again, together with the associated adjustments
to the testsuite.

2008-02-01  Joel Brobecker  <brobecker@adacore.com>

        * breakpoint.c (skip_prologue_sal): New function.
        (resolve_sal_pc): Adjust SAL past prologue if the SAL was
        computed from a line number.

2008-02-01  Joel Brobecker  <brobecker@adacore.com>

        * gdb.base/ending-run.exp: Use the first line of code inside
        function body to test breakpoints.
        * gdb.mi/mi-break.exp, gdb.mi/mi2-break.exp: Adjust the actual
        location where the breakpoint is inserted when using the line
        where a function is declared. Fix typo in the description of
        one of the tests.
        * gdb.mi/mi-simplerun.exp, gdb.mi/mi2-simplerun.exp: Likewise.

Tested on x86-linux.

In the first testcase, the adjustment I made was by avoiding the use
of the line where the function is declared or where the open curly
brace is.  By looking at the testcase, I think it still preserves
the intent of the testcase.  In the second case, I kept the breakpoints
where they are, but adjusted the expected output to reflect the new
behavior.

That leaves the documentation to be updated (and perhaps a NEWS entry?)

OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: skip-prologue.diff --]
[-- Type: text/plain, Size: 1275 bytes --]

Index: breakpoint.c
===================================================================
--- breakpoint.c	(revision 117)
+++ breakpoint.c	(revision 118)
@@ -5446,6 +5446,25 @@ gdb_breakpoint (char *address, char *con
 			       0);
 }
 
+/* Adjust SAL to the first instruction past the function prologue.
+   The end of the prologue is determined using the line table from
+   the debugging information.
+
+   If SAL is already past the prologue, then do nothing.  */
+
+static void
+skip_prologue_sal (struct symtab_and_line *sal)
+{
+  struct symbol *sym = find_pc_function (sal->pc);
+  struct symtab_and_line start_sal;
+
+  if (sym == NULL)
+    return;
+
+  start_sal = find_function_start_sal (sym, 1);
+  if (sal->pc < start_sal.pc)
+    *sal = start_sal;
+}
 
 /* Helper function for break_command_1 and disassemble_command.  */
 
@@ -5460,6 +5479,11 @@ resolve_sal_pc (struct symtab_and_line *
 	error (_("No line %d in file \"%s\"."),
 	       sal->line, sal->symtab->filename);
       sal->pc = pc;
+
+      /* If this SAL corresponds to a breakpoint inserted using
+         a line number, then skip the function prologue if necessary.  */
+      if (sal->explicit_line)
+        skip_prologue_sal (sal);
     }
 
   if (sal->section == 0 && sal->symtab != NULL)

[-- Attachment #3: skip-prologue-tc.diff --]
[-- Type: text/plain, Size: 10318 bytes --]

Index: gdb.base/ending-run.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/ending-run.exp,v
retrieving revision 1.30
diff -u -p -r1.30 ending-run.exp
--- gdb.base/ending-run.exp	1 Jan 2008 22:53:18 -0000	1.30
+++ gdb.base/ending-run.exp	2 Feb 2008 01:08:55 -0000
@@ -55,9 +55,9 @@ gdb_load ${binfile}
 gdb_test "b ending-run.c:1" ".*Breakpoint.*ending-run.c, line 1.*" \
 	"bpt at line before routine"
 
-gdb_test "b ending-run.c:13" \
-	".*Note.*also.*Breakpoint 2.*ending-run.c, line 13.*" \
-	"b ending-run.c:13, one"
+gdb_test "b ending-run.c:14" \
+	".*Note.*also.*Breakpoint 2.*ending-run.c, line 14.*" \
+	"b ending-run.c:14, one"
 
 # Set up to go to the next-to-last line of the program
 #
@@ -67,7 +67,7 @@ gdb_test "b ending-run.c:31" ".*Breakpoi
 # as line "13".  Then try to clear it--this should work.
 #
 gdb_run_cmd
-gdb_test "" ".*Breakpoint.*1.*callee.*13.*" "run"
+gdb_test "" ".*Breakpoint.*1.*callee.*14.*" "run"
 
 gdb_test "cle" ".*Deleted breakpoints 1 2.*" "clear worked"
 send_gdb "i b\n"
@@ -86,30 +86,17 @@ gdb_expect {
 # Test some other "clear" combinations
 #
 gdb_test "b ending-run.c:1" ".*Breakpoint.*4.*"
-gdb_test "b ending-run.c:13" ".*Note.*also.*Breakpoint.*5.*" "b ending-run.c:13, two"
-gdb_test "cle ending-run.c:13" \
-	".*Deleted breakpoint 5.*" "Only cleared 1 by line"
-
-send_gdb "inf line ending-run.c:13\n"
-gdb_expect {
-    -re ".*address (0x\[0-9a-fA-F]*).*$gdb_prompt $" {
-        set line_eight $expect_out(1,string)
-        gdb_test "b 13" ".*Breakpoint.*6.*"
-        gdb_test "cle *$line_eight" ".*Deleted breakpoints 4 6.*" "Clear 2 by address"
-    }
-    -re ".*$gdb_prompt $" {
-        fail "need to fix test for new compile outcome"
-    }
-}
+gdb_test "b ending-run.c:14" ".*Note.*also.*Breakpoint.*5.*" "b ending-run.c:14, two"
+gdb_test "cle ending-run.c:14" \
+	".*Deleted breakpoints 4 5.*" "Cleared 2 by line"
 
 send_gdb "inf line ending-run.c:14\n"
 gdb_expect {
     -re ".*address (0x\[0-9a-fA-F]*).*$gdb_prompt $" {
         set line_nine $expect_out(1,string)
-        gdb_test "b ending-run.c:14" ".*Breakpoint 7.*ending-run.c, line 14.*"
-        gdb_test "b *$line_nine" ".*Note.*also.*Breakpoint 8.*" "Breakpoint 7 at *ending-run.c:14"
-        gdb_test "c" ".*Breakpoint.*7.*callee.*14.*"
-        gdb_test "cle" ".*Deleted breakpoints 7 8.*" "Clear 2 by default"
+        gdb_test "b ending-run.c:14" ".*Breakpoint 6.*ending-run.c, line 14.*"
+        gdb_test "b *$line_nine" ".*Note.*also.*Breakpoint 7.*" "Breakpoint 7 at *ending-run.c:14"
+        gdb_test "cle" ".*Deleted breakpoints 6 7.*" "Clear 2 by default"
     }
     -re ".*$gdb_prompt $" {
         fail "need to fix test for new compile outcome"
Index: gdb.mi/mi-break.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-break.exp,v
retrieving revision 1.15
diff -u -p -r1.15 mi-break.exp
--- gdb.mi/mi-break.exp	1 Feb 2008 16:24:47 -0000	1.15
+++ gdb.mi/mi-break.exp	2 Feb 2008 01:09:31 -0000
@@ -87,12 +87,12 @@ proc test_tbreak_creation_and_listing {}
              "insert temp breakpoint at basics.c:callee2"
 
     mi_gdb_test "444-break-insert -t basics.c:$line_callee3_head" \
-            "444\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",${fullname},line=\"$line_callee3_head\",times=\"0\"\}" \
-             "insert temp breakpoint at basics.c:\$line_callee3_body"
+            "444\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",${fullname},line=\"$line_callee3_body\",times=\"0\"\}" \
+             "insert temp breakpoint at basics.c:\$line_callee3_head"
 
     # Getting the quoting right is tricky.  That is "\"<file>\":$line_callee4_head"
     mi_gdb_test "555-break-insert -t \"\\\"${srcfile}\\\":$line_callee4_head\"" \
-            "555\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",${fullname},line=\"$line_callee4_head\",times=\"0\"\}" \
+            "555\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",${fullname},line=\"$line_callee4_body\",times=\"0\"\}" \
              "insert temp breakpoint at \"<fullfilename>\":\$line_callee4_head"
 
     mi_gdb_test "666-break-list" \
Index: gdb.mi/mi-simplerun.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-simplerun.exp,v
retrieving revision 1.17
diff -u -p -r1.17 mi-simplerun.exp
--- gdb.mi/mi-simplerun.exp	1 Jan 2008 22:53:20 -0000	1.17
+++ gdb.mi/mi-simplerun.exp	2 Feb 2008 01:09:32 -0000
@@ -52,7 +52,9 @@ proc test_breakpoints_creation_and_listi
     global hex
 
     set line_callee4_head  [gdb_get_line_number "callee4 ("]
+    set line_callee4_body  [expr $line_callee4_head + 2]
     set line_callee3_head  [gdb_get_line_number "callee3 ("]
+    set line_callee3_body  [expr $line_callee3_head + 2]
     set line_callee2_head  [gdb_get_line_number "callee2 ("]
     set line_callee2_body  [expr $line_callee2_head + 2]
     set line_main_head     [gdb_get_line_number "main ("]
@@ -75,11 +77,11 @@ proc test_breakpoints_creation_and_listi
              "insert breakpoint at basics.c:callee2"
 
     mi_gdb_test "202-break-insert basics.c:$line_callee3_head" \
-             "202\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",line=\"$line_callee3_head\",times=\"0\"\}" \
+             "202\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",line=\"$line_callee3_body\",times=\"0\"\}" \
              "insert breakpoint at basics.c:\$line_callee3_head"
 
     mi_gdb_test "203-break-insert \"\\\"${srcfile}\\\":$line_callee4_head\"" \
-             "203\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",line=\"$line_callee4_head\",times=\"0\"\}" \
+             "203\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",line=\"$line_callee4_body\",times=\"0\"\}" \
              "insert breakpoint at \"<fullfilename>\":\$line_callee4_head"
 
     mi_gdb_test "204-break-list" \
Index: gdb.mi/mi2-break.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-break.exp,v
retrieving revision 1.8
diff -u -p -r1.8 mi2-break.exp
--- gdb.mi/mi2-break.exp	1 Jan 2008 22:53:20 -0000	1.8
+++ gdb.mi/mi2-break.exp	2 Feb 2008 01:09:33 -0000
@@ -88,12 +88,12 @@ proc test_tbreak_creation_and_listing {}
              "insert temp breakpoint at basics.c:callee2"
 
     mi_gdb_test "444-break-insert -t basics.c:$line_callee3_head" \
-             "444\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",${fullname},line=\"$line_callee3_head\",times=\"0\"\}" \
-             "insert temp breakpoint at basics.c:\$line_callee3_body"
+             "444\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",${fullname},line=\"$line_callee3_body\",times=\"0\"\}" \
+             "insert temp breakpoint at basics.c:\$line_callee3_head"
 
     # Getting the quoting right is tricky.  That is "\"<file>\":$line_callee4_head"
     mi_gdb_test "555-break-insert -t \"\\\"${srcfile}\\\":$line_callee4_head\"" \
-             "555\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",${fullname},line=\"$line_callee4_head\",times=\"0\"\}" \
+             "555\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"del\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",${fullname},line=\"$line_callee4_body\",times=\"0\"\}" \
              "insert temp breakpoint at \"<fullfilename>\":\$line_callee4_head"
 
     mi_gdb_test "666-break-list" \
Index: gdb.mi/mi2-simplerun.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-simplerun.exp,v
retrieving revision 1.8
diff -u -p -r1.8 mi2-simplerun.exp
--- gdb.mi/mi2-simplerun.exp	1 Jan 2008 22:53:20 -0000	1.8
+++ gdb.mi/mi2-simplerun.exp	2 Feb 2008 01:09:34 -0000
@@ -52,7 +52,9 @@ proc test_breakpoints_creation_and_listi
     global hex
 
     set line_callee4_head  [gdb_get_line_number "callee4 ("]
+    set line_callee4_body  [expr $line_callee4_head + 2]
     set line_callee3_head  [gdb_get_line_number "callee3 ("]
+    set line_callee3_body  [expr $line_callee3_head + 2]
     set line_callee2_head  [gdb_get_line_number "callee2 ("]
     set line_callee2_body  [expr $line_callee2_head + 2]
     set line_main_head     [gdb_get_line_number "main ("]
@@ -75,11 +77,11 @@ proc test_breakpoints_creation_and_listi
              "insert breakpoint at basics.c:callee2"
 
     mi_gdb_test "202-break-insert basics.c:$line_callee3_head" \
-             "202\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",line=\"$line_callee3_head\",times=\"0\"\}" \
+             "202\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee3\",file=\".*basics.c\",line=\"$line_callee3_body\",times=\"0\"\}" \
              "insert breakpoint at basics.c:\$line_callee3_head"
 
     mi_gdb_test "203-break-insert \"\\\"${srcfile}\\\":$line_callee4_head\"" \
-             "203\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",line=\"$line_callee4_head\",times=\"0\"\}" \
+             "203\\^done,bkpt=\{number=\"4\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",line=\"$line_callee4_body\",times=\"0\"\}" \
              "insert breakpoint at \"<fullfilename>\":\$line_callee4_head"
 
     mi_gdb_test "204-break-list" \

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

[Daniel Jacobowitz]

On Fri, Feb 01, 2008 at 05:19:45PM -0800, Joel Brobecker wrote:
> As I said yesterday, the idea eventually got accepted by everyone.
> Here is the patch again, together with the associated adjustments
> to the testsuite.

As no one has disagreed with your interpretation :-), this is OK.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> > As I said yesterday, the idea eventually got accepted by everyone.
> > Here is the patch again, together with the associated adjustments
> > to the testsuite.
> 
> As no one has disagreed with your interpretation :-), this is OK.

Great (Yay! :-). Patch now checked in.

Thanks!
-- 
Joel