gdb: fix selecting tail-call frames by name

I noticed that attempting to select a tail-call frame using 'frame
function NAME' wouldn't work:

  (gdb) bt
  #0  func_that_never_returns () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:49
  #1  0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
  #2  0x00000000004011a5 in main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:70
  (gdb) frame function func_that_tail_calls
  No frame for function "func_that_tail_calls".
  (gdb) up
  #1  0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
  59	  func_that_never_returns ();
  (gdb) disassemble
  Dump of assembler code for function func_that_tail_calls:
     0x000000000040117a <+0>:	push   %rbp
     0x000000000040117b <+1>:	mov    %rsp,%rbp
     0x000000000040117e <+4>:	call   0x40116c <func_that_never_returns>
  End of assembler dump.
  (gdb)

The problem is that the 'function' mechanism uses get_frame_pc() and
then compares the address returned with the bounds of the function
we're looking for.

So in this case, the bounds of func_that_tail_calls are 0x40117a to
0x401183, with 0x401183 being the first address _after_ the function.

However, because func_that_tail_calls ends in a tail call, then the
get_frame_pc() is 0x401183, the first address after the function.  As
a result, GDB fails to realise that frame #1 is inside the function
we're looking for, and the lookup fails.

The fix is to use get_frame_address_in_block, which will return an
adjusted address, in this case, 0x401182, which is within the function
bounds.  Now the lookup works:

  (gdb) frame function func_that_tail_calls
  #1  0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
  59	  func_that_never_returns ();
  (gdb)

I've extended the gdb.base/frame-selection.exp test to cover this
case.

0 files changed, 0 insertions, 0 deletions