RE: cannot find bounds of function error

RE: cannot find bounds of function error

[vijay nag]

Hello gdb-veterans,

My latest gdb-7.5  barfs out  "cannot find bounds of current function"
error when it encounters GNU_IFUNC while executing one line of code at
a time
using "next" command

(gdb) n
224	      if (1==fscanf(rva, "%d", &val)) {
(gdb) n
225		if (val) {
(gdb) n
237	      fclose(rva);
(gdb) n
242	      } else if (val) {
(gdb) n
252	  if (getenv("ARGV0")) {
(gdb) n
256	  init(argc, argv,
(gdb) n
268	  priv_init();
(gdb) n
273	  config.argv0short = strrchr(argv[0], '/');
(gdb) p &strrchr
$1 = (<text gnu-indirect-function variable, no debug info> *)
0x13b1b600 <strrchr>
(gdb) n
0x08048430 in ?? ()
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb)

The corresponding assembly before strrchr func here is as below

0x122b6ca7 <main+498>   mov    0xc(%ebp),%ebx

                              │
   │0x122b6caa <main+501>   movl   $0x2f,0x4(%esp)

                                  │
   │0x122b6cb2 <main+509>   mov    (%ebx),%eax

                                  │
   │0x122b6cb4 <main+511>   mov    %eax,(%esp)

                                  │
   │0x122b6cb7 <main+514>   call   0x8048430

Here 0x8048430 appears to be a call to PLT and entry for strrchr seems
to be resolved already

(gdb) p /x *0x178ff5d8
$3 = 0x13b3b0d0
(gdb) info line *0x13b3b0d0
Line 42 of "../sysdeps/i386/i686/multiarch/strrchr-sse2-bsf.S" starts
at address 0x13b3b0d0 <__strrchr_sse2_bsf> and ends at 0x13b3b0d4
<__strrchr_sse2_bsf+4>.
(gdb)

Re: cannot find bounds of function error

[Jan Kratochvil]

On Wed, 24 Jul 2013 11:44:15 +0200, vijay nag wrote:
> My latest gdb-7.5  barfs out  "cannot find bounds of current function"
> error when it encounters GNU_IFUNC while executing one line of code at
> a time using "next" command

Sorry I did not analyze exactly your case but ensure your glibc contains this
patch fixing how GDB deals with gnu-ifuncs:

	commit f85fa27058eb7d4b56b8deaf885064cf8d730f68
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Thu Aug 9 16:04:37 2012 -0700
	    Avoid DWARF definition DIE on ifunc symbols

Besides that there is already stable gdb-7.6 but I do not know about any
specific change there for gnu-ifunc.


Jan

Re: cannot find bounds of function error

[vijay nag]

On Wed, Jul 24, 2013 at 6:19 PM, vijay nag <vijunag@gmail.com> wrote:
>
>
> On Wednesday, July 24, 2013, Jan Kratochvil <jan.kratochvil@redhat.com>
> wrote:
>> On Wed, 24 Jul 2013 11:44:15 +0200, vijay nag wrote:
>>> My latest gdb-7.5  barfs out  "cannot find bounds of current function"
>>> error when it encounters GNU_IFUNC while executing one line of code at
>>> a time using "next" command
>>
>> Sorry I did not analyze exactly your case but ensure your glibc contains
>> this
>> patch fixing how GDB deals with gnu-ifuncs:
>>
>>         commit f85fa27058eb7d4b56b8deaf885064cf8d730f68
>>         Author: H.J. Lu <hjl.tools@gmail.com>
>>         Date:   Thu Aug 9 16:04:37 2012 -0700
>>             Avoid DWARF definition DIE on ifunc symbols
>>
>> Besides that there is already stable gdb-7.6 but I do not know about any
>> specific change there for gnu-ifunc.
>>
>>
>> Jan
>>
> Nice to hear from you again and I appreciate your quick turn-around. I shall
> patch the changes to my glibc and check if that is just enough for the
> gdb-7.5 to get going.
>
> Thanks


I do see the patch in my glibc-2.17. What could be the issue here ?

Re: cannot find bounds of function error

[vijay nag]

On Wed, Jul 24, 2013 at 6:58 PM, vijay nag <vijunag@gmail.com> wrote:
> On Wed, Jul 24, 2013 at 6:19 PM, vijay nag <vijunag@gmail.com> wrote:
>>
>>
>> On Wednesday, July 24, 2013, Jan Kratochvil <jan.kratochvil@redhat.com>
>> wrote:
>>> On Wed, 24 Jul 2013 11:44:15 +0200, vijay nag wrote:
>>>> My latest gdb-7.5  barfs out  "cannot find bounds of current function"
>>>> error when it encounters GNU_IFUNC while executing one line of code at
>>>> a time using "next" command
>>>
>>> Sorry I did not analyze exactly your case but ensure your glibc contains
>>> this
>>> patch fixing how GDB deals with gnu-ifuncs:
>>>
>>>         commit f85fa27058eb7d4b56b8deaf885064cf8d730f68
>>>         Author: H.J. Lu <hjl.tools@gmail.com>
>>>         Date:   Thu Aug 9 16:04:37 2012 -0700
>>>             Avoid DWARF definition DIE on ifunc symbols
>>>
>>> Besides that there is already stable gdb-7.6 but I do not know about any
>>> specific change there for gnu-ifunc.
>>>
>>>
>>> Jan
>>>
>> Nice to hear from you again and I appreciate your quick turn-around. I shall
>> patch the changes to my glibc and check if that is just enough for the
>> gdb-7.5 to get going.
>>
>> Thanks
>
>
> I do see the patch in my glibc-2.17. What could be the issue here ?

Jan,

First of all,  glibc-2.17 seems to be having the fix that you mentioned.

Second of all, I upgraded gdb to 7.6 and still encountering the same problem.

Gdb is confused when the program jumps to PLT in-order to execute
GNU-IFUNC and any number of "Next" command will not make the program
proceed any further.

(gdb) p $eip
$1 = (void (*)()) 0x8048430
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) display $eip

1: $eip = (void (*)()) 0x8048430
(gdb)
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) p $eip
$2 = (void (*)()) 0x8048430
(gdb)


I was looking the code diff of "step_once" function in the version 7.6 and 6.3

infcmd.c
       const char *name;

        if (find_pc_partial_function (pc, &name,
              &tp->control.step_range_start,
              &tp->control.step_range_end) == 0)
    error (_("Cannot find bounds of current function"));

        target_terminal_ours ();
        printf_filtered (_("Single stepping until exit from function %s,"
         "\nwhich has no line number information.\n"),
             name);
      }

Earlier version had  a plain printf for the error line, where as in
the newer versions it has been replaced by error_() which seems to be
unwinding the current gdb stack by doing a long-jump.  Any statements
after error() are superfluously existing without any effect.