[RFA] Patch to skip_prologue_using_sal() for oneline stub functions

[RFA] Patch to skip_prologue_using_sal() for oneline stub functions

[Fred Fish]

If a function optimizes down to a single return instruction, there is
no prologue, and skip_prologue_using_sal will return a PC that is
probably the first instruction of the next following function.  In
this case, we want to return the start_pc, so that the caller will
know that it needs to run the architecture specific prologue scanner
to figure out what is going on.

This fixes the following failures for MIPS:

  FAIL: gdb.base/break.exp: breakpoint small function, optimized file
  FAIL: gdb.base/break.exp: run until function breakpoint, optimized file
  FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file

-Fred

============================================================================

2006-05-10  Fred Fish  <fnf@specifix.com>

	* symtab.c (skip_prologue_using_sal): Handle single line functions
	like "foo(){}", which may optimize down to a single return inst.

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.146
diff -c -p -r1.146 symtab.c
*** symtab.c	17 Dec 2005 22:34:03 -0000	1.146
--- symtab.c	10 May 2006 14:19:07 -0000
*************** skip_prologue_using_sal (CORE_ADDR func_
*** 4030,4035 ****
--- 4030,4040 ----
    prologue_sal = find_pc_line (start_pc, 0);
    if (prologue_sal.line != 0)
      {
+       /* If there is only one sal that covers the entire function,
+ 	 then it is probably a single line function, like
+ 	 "foo(){}". */
+       if (prologue_sal.end == end_pc)
+ 	return start_pc;
        while (prologue_sal.end < end_pc)
  	{
  	  struct symtab_and_line sal;

Re: [RFA] Patch to skip_prologue_using_sal() for oneline stub functions

[Jim Blandy]

Fred Fish <fnf@specifix.com> writes:
> If a function optimizes down to a single return instruction, there is
> no prologue, and skip_prologue_using_sal will return a PC that is
> probably the first instruction of the next following function.  In
> this case, we want to return the start_pc, so that the caller will
> know that it needs to run the architecture specific prologue scanner
> to figure out what is going on.
>
> This fixes the following failures for MIPS:
>
>   FAIL: gdb.base/break.exp: breakpoint small function, optimized file
>   FAIL: gdb.base/break.exp: run until function breakpoint, optimized file
>   FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file
>
> -Fred
>
> ============================================================================
>
> 2006-05-10  Fred Fish  <fnf@specifix.com>
>
> 	* symtab.c (skip_prologue_using_sal): Handle single line functions
> 	like "foo(){}", which may optimize down to a single return inst.

This looks reasonable; have you tested on IA-32, too?

Re: [RFA] Patch to skip_prologue_using_sal() for oneline stub functions

[Fred Fish]

On Wednesday 10 May 2006 18:21, Jim Blandy wrote:
> This looks reasonable; have you tested on IA-32, too?

I tested it with an i686-pc-linux-gnu target, if that is what you
mean.  There were no regressions or other changes in the gdb testsuite
results.

-Fred

Re: [RFA] Patch to skip_prologue_using_sal() for oneline stub functions

[Jim Blandy]

Fred Fish <fnf@specifix.com> writes:
> On Wednesday 10 May 2006 18:21, Jim Blandy wrote:
>> This looks reasonable; have you tested on IA-32, too?
>
> I tested it with an i686-pc-linux-gnu target, if that is what you
> mean.  There were no regressions or other changes in the gdb testsuite
> results.

All right.  Go ahead and commit, then.

Re: [RFA] Patch to skip_prologue_using_sal() for oneline stub functions

[Mark Kettenis]

> From: Fred Fish <fnf@specifix.com>
> Date: Wed, 10 May 2006 11:13:50 -0400
> 
> If a function optimizes down to a single return instruction, there is
> no prologue, and skip_prologue_using_sal will return a PC that is
> probably the first instruction of the next following function.  In
> this case, we want to return the start_pc, so that the caller will
> know that it needs to run the architecture specific prologue scanner
> to figure out what is going on.

Hmm, this is not what the mips_skip_prologue() does.  If you return
START_PC, it will use *that* as the ed of the prologue.  But this
probably is a good thing since we really want to avoid running the
architecture-specific prologue scanner if we can.

That said, how does this handle functions like:

void
foo(void)
{
}

or

void
foo (void)
{
  return;
}

Did you check that?

Re: [RFA] Patch to skip_prologue_using_sal() for oneline stub functions

[Fred Fish]

On Saturday 13 May 2006 05:28, Mark Kettenis wrote:
> That said, how does this handle functions like:
> <examples>
> Did you check that?

I retested with the following sourcefile, printed here with line
numbers for reference:

    1   void first ()
    2   {
    3   }
    4
    5   void oneline1(void) { }
    6
    7   void oneline2(void) { return; }
    8
    9   void twoline1(void) {
   10   }
   11
   12   void twoline2(void) {
   13     return; }
   14
   15   void threeline1 (void)
   16   {
   17   }
   18
   19   void fourline (void)
   20   {
   21     return;
   22   }
   23
   24   void last (void)
   25   {
   26   }

Here is the .gdbinit file I used:

  br first
  br oneline1
  br oneline2
  br twoline1
  br twoline2
  br threeline1
  br fourline
  br last

First try the old gdb prior to the change: Notice that every
breakpoint gets set at the function AFTER the one it was supposed to
be set at:

	$ ./gdb-old -nw -nx -x x.gdb x
	GNU gdb 6.4
	Copyright 2005 Free Software Foundation, Inc.
	GDB is free software, covered by the GNU General Public License, and you are
	welcome to change it and/or distribute copies of it under certain conditions.
	Type "show copying" to see the conditions.
	There is absolutely no warranty for GDB.  Type "show warranty" for details.
	This GDB was configured as "--host=i686-pc-linux-gnu --target=sb1-elf"...
	Breakpoint 1 at 0xa0020330: file x1.c, line 5.
	Breakpoint 2 at 0xa0020338: file x1.c, line 7.
	Breakpoint 3 at 0xa0020340: file x1.c, line 10.
	Breakpoint 4 at 0xa0020348: file x1.c, line 13.
	Breakpoint 5 at 0xa0020350: file x1.c, line 17.
	Breakpoint 6 at 0xa0020358: file x1.c, line 22.
	Breakpoint 7 at 0xa0020360: file x1.c, line 26.
	Breakpoint 8 at 0xa0020368
	(gdb) quit

BTW, for the above, breakpoint 8 actually gets set at the function followoing last():

	(gdb) x/i 0xa0020368
	0xa0020368 <__do_global_ctors_aux>:     lui     v0,0xa002


Now after the change.  They are all correct, I believe, although the breakpoint
for fourline would probably look better from a source perspective if it said
line 21 instead of line 22.

	$ ./gdb-new -nw -nx -x x.gdb x
	GNU gdb 6.4
	Copyright 2005 Free Software Foundation, Inc.
	GDB is free software, covered by the GNU General Public License, and you are
	welcome to change it and/or distribute copies of it under certain conditions.
	Type "show copying" to see the conditions.
	There is absolutely no warranty for GDB.  Type "show warranty" for details.
	This GDB was configured as "--host=i686-pc-linux-gnu --target=sb1-elf"...
	Breakpoint 1 at 0xa0020328: file x1.c, line 3.
	Breakpoint 2 at 0xa0020330: file x1.c, line 5.
	Breakpoint 3 at 0xa0020338: file x1.c, line 7.
	Breakpoint 4 at 0xa0020340: file x1.c, line 10.
	Breakpoint 5 at 0xa0020348: file x1.c, line 13.
	Breakpoint 6 at 0xa0020350: file x1.c, line 17.
	Breakpoint 7 at 0xa0020358: file x1.c, line 22.
	Breakpoint 8 at 0xa0020360: file x1.c, line 26.
	(gdb)

For reference, here is a disassembly:

	(gdb) x/30i 0xa0020328
	0xa0020328 <first>:     jr      ra
	0xa002032c <first+4>:   nop
	0xa0020330 <oneline1>:  jr      ra
	0xa0020334 <oneline1+4>:        nop
	0xa0020338 <oneline2>:  jr      ra
	0xa002033c <oneline2+4>:        nop
	0xa0020340 <twoline1>:  jr      ra
	0xa0020344 <twoline1+4>:        nop
	0xa0020348 <twoline2>:  jr      ra
	0xa002034c <twoline2+4>:        nop
	0xa0020350 <threeline1>:        jr      ra
	0xa0020354 <threeline1+4>:      nop
	0xa0020358 <fourline>:  jr      ra
	0xa002035c <fourline+4>:        nop
	0xa0020360 <last>:      jr      ra
	0xa0020364 <last+4>:    nop
	0xa0020368 <__do_global_ctors_aux>:     lui     v0,0xa002

-Fred