watchpoint and function epilogue

watchpoint and function epilogue

[Christophe LYON]

Hi all,

When generating Dwarf debug_frame information with my compiler, I 
discovered a regression in the recurse.exp test of gdb.base.
The test puts a watchpoint on local variable b and at some time expects 
it to be deleted when going out of function scope.

The recurse function contains:
static int recurse (int a)
{
   int b = 0;

   if (a == 1)
     return 1;

L1:  b = a;
L2:  b *= recurse (a - 1);
L3:  return b;
}

In the test, the watchpoint is created when a==5.
In my case, it triggers 3 times: on lines L1, L2 and L3.

In detail, my Dwarf debug_info for 'b' is
<2><  908>	DW_TAG_variable
		DW_AT_name                  b
		DW_AT_type                  <948>
		DW_AT_location              DW_OP_fbreg -8

The code generated for L3 looks like:
l1: save 'b' into the return-value register
l2: restore SP and RA
l3: return

The debug_frame information says that until l2 (included) SP has been 
updated for the current frame and that RA is saved in the stack.
When reaching l3, it says that RA is restored and that the CFA offset 
changes back to the value it had at function entry.

My analysis is that after executing l2, in break.c:watchpoint_check() 
the location of 'b' is evaluated, and as SP has changed, so has 'b'.
This occurs because watchpoint_check() thinks within_current_scope is true.
Well... we are still in the same function, but as SP has been restored, 
we are not really in the same scope. However, CFA is still unchanged of 
course.


So what is your advice in order to deal with this situation? I guess 
that if the compiler is modified not to generate the instruction that 
restores the CFA_offset, it will work again. Is there any other possibility?

Thanks,


Christophe.

Re: watchpoint and function epilogue

[Jim Blandy]

[Accidentally dropped CC]

On 11/21/05, Christophe LYON <christophe.lyon@st.com> wrote:
> Jim Blandy wrote:
> > On 11/18/05, Christophe LYON <christophe.lyon@st.com> wrote:
> >
> >>So what is your advice in order to deal with this situation? I guess
> >>that if the compiler is modified not to generate the instruction that
> >>restores the CFA_offset, it will work again. Is there any other possibility?
> >
> >
> > You could emit a location list that says that 'b' is optimized out
> > starting at L3.  I'm not sure how GDB would react to that, but it
> > would certainly be GDB's problem if it didn't behave correctly.
> >
>
> Thanks,
>
> I am not sure I can easily do that.
>
> No other target has the same kind of issue?

Actually, lots of targets have this issue. That test in the test suite
often has failures related to the compiler not quite accurately
describing when the variable is deallocated.

Another possibility would be to locate 'b' and all your other local
variables in a made-up internal lexical block which ends at L2.