[RFC] frv-tdep.c: Use refine_prologue_limit() instead of skip_prologue_using_sal()
Kevin Buettner
kevinb@redhat.com
Mon Aug 2 19:42: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
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
More information about the Gdb-patches
mailing list