Fix advance/until and inline frames (PR gdb/26523)
authorPedro Alves <pedro@palves.net>
Thu, 27 Aug 2020 20:03:53 +0000 (21:03 +0100)
committerPedro Alves <pedro@palves.net>
Thu, 27 Aug 2020 20:03:53 +0000 (21:03 +0100)
commitb2b38aa45ba2eb2e7e4c70689d679c4c467eda73
treefd979e988c0709036d8bf78e45bdc1ee750d2789
parentb0191216046cca6affd74b3bfebdb124ad5f428e
Fix advance/until and inline frames (PR gdb/26523)

If you do "tbreak LINENO; c" to advance to an inlined function, GDB
presents the stop at the inline frame instead of at the non-artificial
stack frame:

 (gdb) list 21
 18      static inline __attribute__ ((always_inline)) int
 19      inline_func (int i)
 20      {
 21        return i + 1;
 22      }

 (gdb) tbreak 21
 Temporary breakpoint 3 at 0x55555555516f: advance.cc:21.
 (gdb) c
 Continuing.

 Temporary breakpoint 3, inline_func (i=0) at advance.cc:21
 21        return i + 1;

The logic for this is in stopped_by_user_bp_inline_frame:

 /* Loop over the stop chain and determine if execution stopped in an
    inlined frame because of a breakpoint with a user-specified
    location set at FRAME_BLOCK.  */

 static bool
 stopped_by_user_bp_inline_frame (const block *frame_block, bpstat stop_chain)

If however, you do "advance LINENO" or "until LINENO" instead, GDB
presents the stop at the non-artificial frame:

 (gdb) advance 21
 main () at advance.cc:43
 43        i = inline_func (i);
 (gdb)

"advance" and "until" should really behave like user breakpoints here,
since their location is also user-specified.  As the comment in
gdb.base/advance.exp says, "advance <location>" is really just
syntactic sugar for "tbreak <location>; continue".

Fix this by making stopped_by_user_bp_inline_frame also consider
advance/until breakpoints.

A testcase covering this will be included in the next patch.

gdb/ChangeLog:

PR gdb/26523
* inline-frame.c (stopped_by_user_bp_inline_frame): Also consider
bp_until breakpoints user-specified locations.  Update intro
comment.
gdb/ChangeLog
gdb/inline-frame.c