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

Jan Kratochvil
2011-06-13T16:11:44Z

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