Re: Regression: Re: [PATCH] Fix some i386 unwinder inconcistencies

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 13 Jun 2011 17:37:01 +0200, Mark Kettenis wrote:
> > -PASS: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint
> > +FAIL: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint
> 
> Odd, that tests still passes for me on i386-unknown-openbsd4.9.

From the error message
> > +can't compute CFA for this frame
on Fedora I guess it may be because the compiler there does not produce the
optimized DWARF form:
    <35>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)


> PASS: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint
> 
> Something did change though.  Before my change:

In both cases on Fedora it stops at the same place:
0x080483e0 in func () at ./gdb.base/watchpoint-cond-gone.c:28^M

Which seems correct to me as it is -O0 -g code, therefore without variable
tracking for instruction-precise DW_AT_location, therefore variables become
invalid by the `leave' instruction:

 80483df:       c9                      leave
 80483e0:       c3                      ret


> Something did change though.  Before my change:
> So the watchpoint went out of scope before the function returned.

Yes, because the frame got destroyed, the variable is no longer valid.


>   Whereas after my change:
> the watchpoint went out of scope when the function returned, as I believe it should.

I do not agree, when you stop at the `ret' instruction above the watchpoint
should be already deleted there because its watched variable is no longer
valid.


> > -XFAIL: gdb.mi/mi-watch.exp: sw: watchpoint trigger (stopped at wrong place)
> > +XFAIL: gdb.mi/mi-watch.exp: sw: watchpoint trigger (unknown output after running)
> > -XFAIL: gdb.mi/mi2-watch.exp: sw: watchpoint trigger (stopped at wrong place)
> > +XFAIL: gdb.mi/mi2-watch.exp: sw: watchpoint trigger (unknown output after running)
> 
> Ok, I'm seeing these as well.  Didn't classify these as a regression
> since they went from XFAIL to XFAIL.  They seem to be related to the
> fact that I changed get_frame_pc into get_frame_func.  That change is
> correct though.

If you believe it is correct then you should fix the testcase.
I find "(stopped at wrong place)"->"(unknown output after running)" to be
a regression.

But as there is printed:
+&"can't compute CFA for this frame\n"^M
I find the message as a regression on its own.


> I think this can be avoided by implementing the
> in_function_epilogue_p() gdbarch method for i386/amd64.  In fact, that
> method already seems to be implemented.  It just isn't registered.

After `leave' the local variables are no longer valid, they are already
located under $sp and can be overwritten by any interrupt that time, no GDB
unwinder can fix it.

Also for the epilogue unwinder you would need to somehow fix:
1441	  /* This restriction could be lifted if other unwinders are known to
1442	     compute the frame base in a way compatible with the DWARF
1443	     unwinder.  */
1444	  if (! frame_unwinder_is (this_frame, &dwarf2_frame_unwind))
1445	    error (_("can't compute CFA for this frame"));



Thanks,
Jan