Re: GDB 4.17 Patch for stack aligned i386 code

[Michael Snyder <msnyder at cygnus dot com>]

John, Eli, Jim et al, 

Nick Duffek also recently did some work related to frameless
function backtraces on the X86.  I don't know whether his 
work is checked into the main trunk.  I'd like to see him
involved in this discussion, so that we don't wind up with
two solutions to the same problem.

				Thanks,
				Michael

John Wehle wrote:
> 
> > Is it possible to tell a bit more about the problem, and how is it
> > solved?
> 
> It's desirable to omit the frame pointer when compiling leaf functions
> when targeting the x86 processor as this provides another hard register
> (%ebp) which can be used by the register allocators.  Using
> -momit-leaf-frame-pointer instructs GCC to compile code in this manner.
> Unfortunately GDB has a rather strong belief that %ebp always points to
> the frame and is unable to locate function arguments or local variables
> when the frame pointer is omitted.  The changes allow GDB to locate the
> frame based on the value in %esp.
> 
> >  Perhaps even a short test case, before and after the change?
> 
> An example is backtracing through sigtramps on Solaris (the Solaris library
> contains functions which don't use %ebp as the frame pointer).  For example
> ... the backtrace from gdb.base/a1-selftest.exp (without my patch) shows:
> 
> #0  0x80068745 in _libc_sigprocmask ()
> #1  0x80098763 in sigprocmask ()
> #2  0x8107cb3 in rl_signal_handler (sig=134509072) at signals.c:156
> #3  0x800685b1 in _sigacthandler ()
> #4  <signal handler called>
> #5  0x800682b8 in _libc_read ()
> #6  0x8101ef9 in rl_getc (stream=0x800a9ad4) at readline.c:3123
> #7  0x80ffa5b in rl_read_key () at readline.c:578
> 
> The correct backtrace is:
> 
> #0  0x80068745 in _libc_sigprocmask ()
> #1  0x80098763 in sigprocmask ()
> #2  0x8107fe7 in rl_signal_handler (sig=134509096) at signals.c:156
> #3  0x800685b1 in _sigacthandler ()
> #4  <signal handler called>
> #5  0x800682b8 in _libc_read ()
> #6  0x80098b33 in read ()
> #7  0x810222d in rl_getc (stream=0x81639a0) at readline.c:3123
> #8  0x80ffd8f in rl_read_key () at readline.c:578
> 
> > Also, do the original problems affect Solaris alone, or are they
> > common to all gcc/x86-based architectures?
> 
> They're common to all gcc/x86-based architectures.
> 
> > It's quite difficult to judge a large patch for two different problems
> > without having a more-or-less clear notion of the issues involved.
> 
> Actually they're slight variations of same problem which is how to locate
> the frame.  The GDB patch in question supports locating the frame for x86
> code:
> 
>   1) In a leaf function where the frame pointer has been omitted.  GCC
>      currently supports generating this if -momit-leaf-frame-pointer is
>      specified.  It's desirable to make this the default once debugging
>      support is in place.
> 
>   2) In a function where the frame pointer has been omitted and the stack
>      pointer is unchanging.  For example:
> 
>        int global;
> 
>        void
>        unchanging_sp(int a, int b)
>          {
> 
>          global = a + b;
>          print_global();
>          }
> 
>      I have a patch for GCC to support omitting the frame pointer in this
>      case which has been delayed pending debugger support.  It's desirable
>      to also have this as part of the default x86 code generation strategy.
> 
>   3) In a function where "andl" has been used to align the frame.  I have
>      an experimental patch for GCC to support aligning the frame in this
>      fashion in order to improve x86 floating point performance.
> 
> The original GDB work was done in November 1998 and January 1999.  I'd be
> happy to dust things off on my side in order to get these changes installed
> if you're interested in working with me.  BTW, the necessary paperwork
> is already on file.
> 
> -- John
> -------------------------------------------------------------------------
> |   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
> |    John Wehle    |     Fax: 1-215-540-5495  |                         |
> -------------------------------------------------------------------------