Re: [RFC] frv-tdep.c: Use refine_prologue_limit() instead of skip_prologue_using_sal()

[Kevin Buettner <kevinb@redhat.com>]

On Sat, 31 Jul 2004 13:37:55 -0400
Andrew Cagney <cagney@gnu.org> wrote:

> More seriously, what's the case you've encountered?

It's pthread_start_thread() from glibc.  Here's the code split up into
SAL units with the line number at the right.  (I synthesized this by hand
from "x/i" and "info line" output.  I can provide you with the raw data
if you want...)

Code                                            Line Number     Ref
---------------------------                     -----------     ---
0x2e020  addi sp,-200,sp                        256             A
0x2e024  sti.p fp,@(sp,184)

0x2e028  sethi 0xffff,gr4                       273             B

0x2e02c  addi.p sp,184,fp                       256             C

0x2e030  setlo 0xfd80,gr4                       273             D

0x2e034  movsg lr,gr5                           256             E
0x2e038  stdi.p gr18,@(sp,0)
0x2e03c  ori gr15,0,gr18
0x2e040  sti.p gr5,@(fp,8)

0x2e044  ori gr8,0,gr29                         265             F

0x2e048  stdi.p gr20,@(sp,8)                    256             G
0x2e04c  ori gr8,0,gr19
0x2e050  stdi gr22,@(sp,16)

0x2e054  ldd @(gr4,gr15),gr14                   273             H
0x2e058  calll @(gr14,gr0)

0x2e05c  sethi.p 0xffff,gr4                     276             I
0x2e060  setlo 0xfb20,gr4

0x2e064  sti.p gr8,@(gr19,84)                   273             J

0x2e068  addi gr19,148,gr9                      276             K
0x2e06c  ldd.p @(gr4,gr18),gr14
0x2e070  setlos 0x2,gr8
0x2e074  calll.p @(gr14,gr0)
0x2e078  setlos lo(0x0),gr10

The last prologue SAL is marked "G" in the "Ref" column.

When these SALs are scanned using skip_prologue_using_sal(),
prologue_sal will be initialized to SAL "A".  When the loop
is entered, ``sal'' (local to the loop) is set to "B".  The
following test causes the loop to terminate on the first
iteration:

          if (sal.line >= prologue_sal.line)
            break;

Here, sal.line is 273 and prologue_sal.line is 256.

Thus, skip_prologue_using_sal() returns the end address corresponding
to SAL "A" (which is actually 0x2e028 since the end address is actually
the start address for the next SAL).

By way of contrast, refine_prologue_limit() starts out the same way
initializing ``prologue_sal'' to SAL "A".  Execution of the inner loop
will cause ``prologue_sal'' will be set successively to "C", "E", and
finally "G".  (Note that there will be some/many iterations where
``prologue_sal'' doesn't change.)

As far as I can tell, the only interesting case that
skip_prologue_using_sal() handles is when the line numbers for
successive SALs are monotonically decreasing up to the prologue ->
body transition.

> GDB should be using the dwarf2 debug info when setting the prologue 
> breakpoint[s], how hard is it to do that?

I don't know.  When I became aware of this problem, I considered
just turning on dwarf2 CFI, but I wanted to understand why prologue
analysis was failing first.

Kevin