[i386/fyi] small adjustment to i386 frame code

[Joel Brobecker <brobecker at adacore dot com>]

Hello,

Since this has been discussed here in several occasions...

Since GDB 6.0, the debugger has been using a more sophisticated
frame unwinder. It used to blindly follow the %ebp register, but
no longer does that unless it is sure that the frame base address
has been saved there.

Although the new frame code gives more much more accurate results
most of the time, there are some occasional cases where we have
to unwind through functions which do not follow the ABI, and for
which no frame debugging info seem to be provided. In these particular
cases, the unwinder fails, and a backtrace from such function aborts
prematurely. One such example is WaitForSingleObjectEx (in one of
the windows DLL). I posted the assembly of this function a long while
ago, it's just plain impossible to determine where the frame base is.

Unfortunately for us, that function is used fairly regularly by any
application which would use tasking (a high-level equivalent of threads
in C), which is something relatively common in the Ada world. So we
really need to be able to unwind past that function.

When it comes to unwinding using prologue analysis, there is probably
no perfect solution. Here is the approach we are going to try out:
Follow blindly the %ebp register for "the complicated functions".
And because we've only encountered this type of code in a DLL, we've
limited this hack to code in DLLs. I added a comment in the code
explaining the condition that implements "complicated".

We know there is a risk of %ebp being clobbered, we also know that
%ebp is the base address of the caller's frame, now ours. But that
will at least give us a chance of having the backtrace reach the user
code.

If this is something of general interest, in this form or any variation,
I would be happy to contribute it.

-- 
Joel

Attachment: ebp.diff
Description: Text document