Re: [offbyone RFC] Merge i386newframe

[Andrew Cagney <ac131313 at redhat dot com>]

> Hmm.  I was under the impression that we have this function because on
> some targets (the i386 is one of them) the frame hasn't been setup yet
> when we've stopped on the first instruction of a function.
>
> With CFI, frame or no frame, it is always possible to unwind the PC.  A more complex prologue analysier could also manage to unwind the PC correctly in this case (but at the expense of doing prologue analysis).
>
> The function is called when doing a next and has just stepped into a function.  To make the next faster (no prologue analysis), and the prologue analyzer easier (avoid most common frameless case).
>
> Thing is, it doesn't do anything for:
>
>     (gdb) stepi
>     Stepped into function foo()
>     0x10000    add 8 to sp
>     (gdb) stepi
>     0x10000    store link-register in [sp + 4]
>
> which prologue analyzers should handle but don't `because it is to hard'.  A simple minded suggestion is to limit the prologue analyser to the instruction range [func ... current-pc) so that, when still in the prologue, it only records what really happened.
>
>    Perhaphs it should be superseeded by a method that takes a regcache    instead of a frame (making the non-analysis of the prologue clearer)?
>
> I think that would be a good idea.
>
> Optional.  It should fall back to using standard unwind_pc().

Hmm, why not get dogmatic?  The prologue analyzer shall efficiently, and 
correctly, handle the case of a pc in the prologue.

If that is a given, the pc == function edge case can be handled with:

	if (pc == function)
	  // don't bother with prologue analysis
	  // all registers (except PC/LR) come from next frame
	  return;

or

	for (iaddr = function; iaddr < pc; iaddr += insn length)
	   ... examine instruction ...

either way it will efficiently avoid doing prologue analysis when on the 
first instruction, and in the second case will result in a better analyzer.

Andrew