[Bug gdb/23537] New: Add step-non-pure command

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

Bug ID: 23537
Summary: Add step-non-pure command
Product: gdb
Version: HEAD
Status: NEW
Severity: enhancement
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---

Consider this source:
...
int a = foo1 ();
int b = foo2 ();
int c = foo3 ();
bar (a, b, c);
...
In order to step into bar, we need to do "n, n, n, s".

Now consider an alternative way of writing this (typically used when a, b and c
are only used in the call to bar):
...
bar (foo1 (), foo2(), foo3());
...
Here in order to step into bar, we need to do "s, f, s, f, s, f, s".

Now assume that the foo functions will not do interesting stuff, but just get
certain values, in other words, they're pure functions (no effects except the
return value and their return value depends only on the parameters and/or
global variables).

If the compiler marks these functions as pure, we can introduce a command snp
(step-non-pure) that would step into bar without bothering with the foos. So,
we need to do just "snp".

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

Tom de Vries <vries at gcc dot gnu.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Open question: do we want snp to step into bar if bar is also pure.

If yes, it makes the behaviour of the command less intuitive (I think).

If no, perhaps we need a step-top-level that skips over the foos, and steps
into bar (irregardless of pureness of the foos).

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

Pedro Alves <palves at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
anchoring this on "pureness" seems quite odd to me. A user debugging some code
won't normally know off hand if the functions are pure or not?!

It seems to me that what you really want is "step into the outermost function
call in this line"?

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Pedro Alves from comment #2)

Post by palves at redhat dot com
anchoring this on "pureness" seems quite odd to me. A user debugging some
code won't normally know off hand if the functions are pure or not?!

We talked on #gcc today about perhaps using __attribute__((artificial))
and then having DW_AT_artificial be used for this purpose.

Another possibility here was to have the artificial flag set up
some "skip"s by default, then the user could undo them if desired.

This came up because Johnathan Wakely wanted to make it so that,
by default, you wouldn't step into std::move.

Post by palves at redhat dot com
It seems to me that what you really want is "step into the outermost
function call in this line"?

That's bug 12940.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Pedro Alves from comment #2)

Post by palves at redhat dot com
anchoring this on "pureness" seems quite odd to me.
A user debugging some
code won't normally know off hand if the functions are pure or not?!

Indeed, one won't know in general. And one could argue that that is precisely
why such an instruction can be useful.

Stepping through code you don't known using snp lets you automatically skip
"uninteresting" functions, and step into "interesting" functions, which is
useful if you're stepping through code in order find where something is changed
(in other words, in a situation where the measure "interesting" matches
"non-pure").

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

--- Comment #5 from Pedro Alves <palves at redhat dot com> ---
(In reply to Tom Tromey from comment #3)

Post by tromey at sourceware dot org
(In reply to Pedro Alves from comment #2)

Post by palves at redhat dot com
anchoring this on "pureness" seems quite odd to me. A user debugging some
code won't normally know off hand if the functions are pure or not?!

We talked on #gcc today about perhaps using __attribute__((artificial))
and then having DW_AT_artificial be used for this purpose.
Another possibility here was to have the artificial flag set up
some "skip"s by default, then the user could undo them if desired.
This came up because Johnathan Wakely wanted to make it so that,
by default, you wouldn't step into std::move.

OK, this rings a bell. I chatted about that with Jon and Florian a while ago,
and back then I pointed Jon at that "skip" had then been improved to support
regexps (skip -rfunction). This was almost 2 years ago. __attribute__
((artificial)) came up too. Here's the relevant snippet:

<jwakely> looks like I can use "skip -fu N" for all specializations of a
template, or "skip -rfu ^std::move<.*$" -- awesome
<palves> there's also "skip -gfile file-glob-pattern", for globbing.
like maybe, say: "skip -gfile include/c++/*/bits/*" to skip all internal
details.
<jwakely> for my purposes skipping all internal details is far too much
:)
but std::move and std::forward are just casts to a reference type, so always
skipping them makes sense
<fweimer> jwakely: Couldn't you add __attribute__ ((artificial)) to their
implementation?
<jwakely> fweimer: ooh maybe ... never heard of it
<fweimer> jwakely: glibc does this for its fortify function wrappers.
<jwakely> fweimer: looks useful!
<jwakely> doesn't seem to change the behaviour of stepping into them
<jwakely> or I'm too dumb to use it correctly: move.cc:3:50: warning:
‘__artificial__’ attribute ignored [-Wattributes]

Using attribute artificial irks me somewhat, because I'm not sure marking a
normal function as artificial isn't ... artificial?

An alternative I thought back then that would require no changes to gdb or gcc
was that instead of marking the code, we'd add the "skip -rfu ^std::move<.*$"
to libstdc++'s Python pretty printer stuff, so that users get that by default,
and, users can selectively disable the skipping if they want. I don't know
whether Jon tried that, but I just kind of assumed he would.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
(In reply to Tom de Vries from comment #4)

Post by tromey at sourceware dot org
(In reply to Pedro Alves from comment #2)

Post by palves at redhat dot com
anchoring this on "pureness" seems quite odd to me.
A user debugging some
code won't normally know off hand if the functions are pure or not?!

Indeed, one won't know in general. And one could argue that that is
precisely why such an instruction can be useful.

My issue is with using "pure" as the function's characteristic that determines
whether users normally want to skip a function. It seems orthogonal to me.
"artificial" looks like a much better attribute. But then, I'd think that we
likely want to made gdb's stepping skip those by default instead of adding a
separate command (e.g., do you want new action buttons in IDEs for this new
stepping/nexting kind?)

Post by tromey at sourceware dot org
Stepping through code you don't known using snp lets you automatically skip
"uninteresting" functions, and step into "interesting" functions, which is
useful if you're stepping through code in order find where something is
changed (in other words, in a situation where the measure "interesting"
matches "non-pure").

Sure. But why aren't pure functions interesting? Seems like an orthogonal
concept. The only rationale I can think of is that you can always call it
manually if you skipped past it by mistake, since given the same inputs a pure
function's implementation should go via the same internal code paths.
Still, I'm sceptic. I argue that in practice, "pure" is not the discriminant
that matters most and that what you _really_ want 99% of the time is either bug
12940, or auto-skipping artificial functions.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23537

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Pedro Alves from comment #6)

Post by palves at redhat dot com
(In reply to Tom de Vries from comment #4)

Post by tromey at sourceware dot org
(In reply to Pedro Alves from comment #2)

Post by palves at redhat dot com
anchoring this on "pureness" seems quite odd to me.
A user debugging some
code won't normally know off hand if the functions are pure or not?!

Indeed, one won't know in general. And one could argue that that is
precisely why such an instruction can be useful.

My issue is with using "pure" as the function's characteristic that
determines whether users normally want to skip a function.

The proposal is _not_ 'using "pure" as the function's characteristic that
determines whether users normally want to skip a function'.

The proposal is to allow users to use "pure" as a function's characteristic to
determine whether users want to skip a specific function.

Post by palves at redhat dot com
It seems orthogonal to me.

In my experience, there are specific cases where this overlaps.

Post by palves at redhat dot com
But then, I'd think that we likely want to made gdb's stepping skip those by
default instead of adding a separate command (e.g., do you want new action
buttons in IDEs for this new stepping/nexting kind?)

I don't use IDEs, so I haven't thought it through that far.

Post by palves at redhat dot com

Post by tromey at sourceware dot org
Stepping through code you don't known using snp lets you automatically skip
"uninteresting" functions, and step into "interesting" functions, which is
useful if you're stepping through code in order find where something is
changed (in other words, in a situation where the measure "interesting"
matches "non-pure").

Sure. But why aren't pure functions interesting? Seems like an orthogonal
concept.

Again, I'm _not_ saying pure functions are not interesting. I'm saying there
are scenarios when you're stepping through a program and you're only interested
in non-pure functions.

Post by palves at redhat dot com
The only rationale I can think of is that you can always call it
manually if you skipped past it by mistake, since given the same inputs a
pure function's implementation should go via the same internal code paths.
Still, I'm sceptic. I argue that in practice, "pure" is not the
discriminant that matters most and that what you _really_ want 99% of the
time is either bug 12940, or auto-skipping artificial functions.

I think those make sense in their own right, but I think the same about snp.
Just think of it as way to step through a program with more detail than next,
and less detail than step.

[ Btw, perhaps instead of having a separate snp command, we can add "skip
-pure" or some such. ]