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

[Andrew Cagney <cagney at gnu dot org>]

> 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

What about the corresponding C code?

> 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;

For reference:

      while (prologue_sal.end < end_pc)
        {
          struct symtab_and_line sal;

          sal = find_pc_line (prologue_sal.end, 0);
          if (sal.line == 0)
            break;
          /* Assume that a consecutive SAL for the same (or larger)
             line mark the prologue -> body transition.  */
          if (sal.line >= prologue_sal.line)
            break;

As in:
  28    int foo (int i) { return i * 2; };
would have two SALs at line 28.

          /* The case in which compiler's optimizer/scheduler has
             moved instructions into the prologue.  We look ahead in
             the function looking for address ranges whose
             corresponding line number is less the first one that we
             found for the function.  This is more conservative then
             refine_prologue_limit which scans a large number of SALs
             looking for any in the prologue */
          prologue_sal = sal;
        }

> 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.)

For reference:

      for (i = 2 * max_skip_non_prologue_insns;
           i > 0 && (lim_pc == 0 || addr < lim_pc);
           i--)
        {
          struct symtab_and_line sal;

          sal = find_pc_line (addr, 0);
          if (sal.line == 0)
            break;
          if (sal.line <= prologue_sal.line
              && sal.symtab == prologue_sal.symtab)
            {
              prologue_sal = sal;
            }
          addr = sal.end;
        }


> 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.

Sounds like it should be tweaked.

> > > 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.

dwarf2's prologue info is separate to CFI - its part of the line number 
information - and lets us implement breakpoints past the prologue in a 
portable way.

Andrew