[RFC] frv-tdep.c: Use refine_prologue_limit() instead of skip_prologue_using_sal()
Andrew Cagney
cagney@gnu.org
Tue Aug 3 14:46:00 GMT 2004
> 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
More information about the Gdb-patches
mailing list