Re: Possible improvement to i386 function prologue analysis.

[Andrew Cagney <cagney@gnu.org>]

>>>    Please suggest if it would be worthwhile to work on a 
>>> similar check for 
>>>    special instructions within the for loop in 
>>> i386_analyze_register_saves().
>>>    This will enable it to continue reading saved registers over such 
>>>    occurances.
> 
> 
>   It's a consequence of the introduction of RTL prolog generation in recent
> versions of gcc; before, prologs and epilogs were output as straight
> hard-coded assembler.  Now that they are generated from RTL insns, it is
> possible for the scheduler to move instructions from the body of the
> function into the prologue itself.  While this is good for performance, it
> means that basically _any_ instruction can be found in the prolog.  This
> makes writing the code to disassemble and interpret the prolog a good deal
> more difficult.
> 
> 
>>> It's not as important as getting the stack frame setup right (which is
>>> why the code in i386_analyze_frame_setup is there), but it would
>>> certainly be nice to have it.  There a slight complication though.
>>> The prologue analyzing stuff is also used for implementing
>>> i386_skip_prologue().  Now i386_skip_prologue() shouldn't dwell too
>>> far into the function.  Skipping the instructions we're talking about
>>> here might just do that.

GCC, at -O0, should not be mixing prologue and code body.  Dwarf3 does 
define a function prologue address attribute, and if available GDB 
should use prefer it over the heuristic.

Andrew