RE: Possible improvement to i386 function prologue analysis.

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: gdb-owner On Behalf Of Mark Kettenis
> Sent: 15 October 2004 18:50

>    In the above instance, the function 
> "i386_analyze_register_saves()", 
>    which takes care of populating the frame cache, will fail 
> after reading the first register %edi.
> 
> Hi Ashish,
> 
> Thanks for your mail.  I agree with you analysis.  There's even a
> KFAILing test in the testsuite for a very similar problem.

  It's quite funny that there have been two independent and unrelated posts
on the same subject on the same day!

> -----Original Message-----
> From: gdb-owner On Behalf Of David Lecomber
> Sent: 15 October 2004 14:49

> My knowledge of this area is very limited, but I regularly come across
> bad stack traces in GDB, and I think the problem is in i386-tdep.c 
> i386_analyze_frame_setup

>    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.

and from David's post:

> The code there seems very specific to GNU compilers, 
> expecting either an "enter" - or a pushl %ebp.  
>
> Well, here's what you get from Intel version 7.1 fortran compiler:

  Yep, it basically is written with the knowledge and expectation of a
gcc-generated prolog.  It struck me when I first started looking into how
gdb works that this mechanism, although valid, is essentially fragile.

  I'm not too up on the internals of Dwarf-2, but aren't there features in
it that should make it possible to distinguish epilog instructions from
function body instructions in a reliable way?  Or is that something that
_will_ be possible when Dwarf-3 happens?  Or have I got the totally wrong
end of a stick?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....