[Bug gdb/12940] New: RFE: Step into the last function call on a line

[Bug gdb/12940] New: RFE: Step into the last function call on a line

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12940

           Summary: RFE: Step into the last function call on a line
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: jan.kratochvil@redhat.com


int a (void) { return 1; }
int b (void) { return 2; }
void f (int x) {}
int main (void)
{
  f (a () + b ());
  return 0;
}
-------------------------------------------------------------------------------

Expected:
6      f (a () + b ());
(gdb) stepfunc
f (x=3) at lastfunc.c:3
3    void f (int x) {}

Actual:
6      f (a () + b ());
(gdb) step
a () at lastfunc.c:1
1    int a (void) { return 1; }

Now one has to (according to the number of called functions):
(gdb) step
(gdb) finish
(gdb) step
(gdb) finish
(gdb) step

or:
(gdb) record 
(gdb) next
(gdb) reverse-step
(gdb) reverse-finish 
(gdb) step

or to use:
(gdb) ignorefunc a
(gdb) ignorefunc b
(gdb) step
with:
define ignorefunc
    break $arg0
    commands
        up
        tbreak
        commands
            step
        end
        continue
    end
end

This feature should be doable the right way (to find the last call instruction
during instruction stepping in a line) with the recent DW_TAG_GNU_call_site
markers.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/12940] RFE: Step into the last function call on a line

[crowl at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12940

Lawrence Crowl <crowl at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crowl at google dot com

--- Comment #1 from Lawrence Crowl <crowl at google dot com> 2012-06-27 23:29:41 UTC ---
This feature is highly valuable when debugging modern C++ code.  It is
common to have lines looking like: 

  a = b->f( c->g(), d->h()->x() );

It is often the case that g, h, and x are accessors of some form, and
are usually not the source of bugs.  The bug would typically be in
f.  As outlined above, the current commands needed to step into f are
tedious.  So, one wants to use one command to step from the start of
that statement directly into function f.

Siva Chandra <sivachandra@google.com> has written a Python script that
implements the core part of this feature.  It uses a recent patch to
expose find_pc_line to the Python API,
http://sourceware.org/ml/gdb-patches/2012-05/msg00257.html.

The simplest implementation of the features is to look at all
functions calls for a statement and break on the textually last one in
the assembly code.  I have used a debugger with this implementation,
and it alone is valuable.

There are situations, however, where the simple implementation of the
feature might yield unintended results.

(1) The compiler uses branching internal to a statement that results
in the textually last function in the assembly not being the last
function called in time.

This situation is mostly ignorable.  If not though, the user's
solution is to compile at a lower optimization level.  Otherwise, the
compiler and debugger would need to conspire to present the order
correctly.  That implementation can wait until demonstrated need.

(2) Two functions whose results are combined by non-function code.

  i = f() + g();
  b = f() && g();

In the first case, the compiler could generate the function calls in
either order.  In the second case, f might return false, in which case
g is never executed to step into.

This situation is hard to resolve, as the user's intent is hard to
discern.  Any solution can wait until demonstrated need.

(3) The statement might include implicit conversion functions that
happen as the last call.  In this case, the statement

  i = f(g());

is implemented as

  i = f(g()).operator int();

and the textually last call is to operator int.  The user might not
recognize the implicit conversion as being there, and the step would
go too far.

This situation can be resolved by providing a variant of the
function-step command that ignores implicit function calls when
choosing the last function.

(4) The statement might include a user-defined operator function that
the user does not recognize as a function.  The most common case here
is operator =. In this case, the statement

  t = f(g());

is implemented as

  t.operator=(f(g());

and the textually last call is ot operator =. The user might not
recognize the assignment operator as being a function call, and the
step would go too far.

This situation is by far the most common one that I encounted in 
actual use.  It can be resolved by providing a variant of the
function-step command that ignores assignment operator function calls
when choosing the last function.  Alternately, it could ignore all
operator function calls.

However, even without addressing the situations above, the feature
saves significant debugging time.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/12940] RFE: Step into the last function call on a line

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12940

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat
                   |                            |dot com

--- Comment #2 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2012-10-25 16:39:58 UTC ---
Just if not clear there is DW_TAG_GNU_call_site now to find the function calls.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/12940] RFE: Step into the last function call on a line

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12940

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |archer
                 CC|                            |tromey at redhat dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/12940] RFE: Step into the last function call on a line

[mst.lo at arcor dot de]

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

Michael Stahl <mst.lo at arcor dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mst.lo at arcor dot de,
                   |                            |sbergman at redhat dot com

--- Comment #3 from Michael Stahl <mst.lo at arcor dot de> ---
this would be really quite useful when debugging LibreOffice.

SunStudio dbx had a similar command, and that's the only feature of it that i
miss.

 step to [ function ]

you could even specify optional function to step into.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/12940] RFE: Step into the last function call on a line

[jan.kratochvil at redhat dot com]

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

--- Comment #4 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
If you are willing to specify "function" there is:
(gdb) help advance 
Continue the program up to the given location (same form as args for break
command).
Execution will also stop upon exit from the current stack frame.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/12940] RFE: Step into the last function call on a line

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

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

--- Comment #5 from Hannes Domani <ssbssa at sourceware dot org> ---
It's not in gdb yet, but with my patch series that allows stepping based on the
column debug information [1], you get this with the example from the 1st entry:

(gdb) start
Temporary breakpoint 1 at 0x401653: file gdb-12940.c, line 6, column 6.
Starting program: C:\src\tests\gdb-12940.exe

Temporary breakpoint 1, main () at gdb-12940.c:6
6         f (a () + b ());
             ^
(gdb) nextc
6         f (a () + b ());
                    ^
(gdb) nextc
6         f (a () + b ());
          ^
(gdb) step
f (x=3) at gdb-12940.c:3
3       void f (int x) {}
        ^


[1] https://sourceware.org/pipermail/gdb-patches/2020-May/168673.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.