Possible improvement to i386 function prologue analysis.

Possible improvement to i386 function prologue analysis.

[ashish mittal]

Hi,

This is in reference to GDB's function prologue analysis (and updation 
of  its internal register cache therefrom) on the x86 architecture.
GDB file: gdb/i386-tdep.c

i386_analyze_frame_setup() takes care of
"Check for some special instructions that might be migrated by
         GCC into the prologue and skip them.  At this point in the
         prologue, code should only touch the scratch registers %eax,
         %ecx and %edx,.."

Instances have been observed when GCC generates these instructions 
between the prologue "push" instructions; for example, the following 
from the objdump of gdb:

0807a380 <captured_main>:
 807a380:       55                      push   %ebp
 807a381:       31 c0                   xor    %eax,%eax
 807a383:       89 e5                   mov    %esp,%ebp
 807a385:       57                      push   %edi
 807a386:       31 d2                   xor    %edx,%edx
 807a388:       31 c9                   xor    %ecx,%ecx
 807a38a:       56                      push   %esi
 807a38b:       53                      push   %ebx
 807a38c:       81 ec 4c 01 00 00       sub    $0x14c,%esp

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.

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.
I could work on a possible patch if you agree.

Thanks,
Ashish Mittal.

Re: Possible improvement to i386 function prologue analysis.

[Mark Kettenis]

   Date: Fri, 15 Oct 2004 18:18:50 +0530
   From: ashish mittal <ashishm@linsyssoft.com>

   Hi,

   0807a380 <captured_main>:
    807a380:       55                      push   %ebp
    807a381:       31 c0                   xor    %eax,%eax
    807a383:       89 e5                   mov    %esp,%ebp
    807a385:       57                      push   %edi
    807a386:       31 d2                   xor    %edx,%edx
    807a388:       31 c9                   xor    %ecx,%ecx
    807a38a:       56                      push   %esi
    807a38b:       53                      push   %ebx
    807a38c:       81 ec 4c 01 00 00       sub    $0x14c,%esp

   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.

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

   I could work on a possible patch if you agree.

That'd be great.

Mark

RE: Possible improvement to i386 function prologue analysis.

[Dave Korn]

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

Re: Possible improvement to i386 function prologue analysis.

[Andrew Cagney]

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