Date:	Thu, 18 Sep 1997 19:14:32 +0200
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Subject:	Re: Asm Question
To:	Vik DOT Heyndrickx AT rug DOT ac DOT be (Vik Heyndrickx)
Cc:	djgpp AT delorie DOT com
Message-id:	<01INSRUDSRV48WVYJI@mail>
Organization:	RWTH Aachen, III. physikalisches Institut B
Newsgroups:	comp.os.msdos.djgpp

In article <342115E7 DOT 43D8 AT rug DOT ac DOT be> you wrote:
> Shawn Hargreaves wrote:

> ... 
> > the parameters and local variables are accessed relative to this. The
> > main advantage to this is that the return address will always be at a
> > fixed offset from %ebp, and the version of %ebp from the previous
> > function will be pushed directly after this, so it is easy for debuggers
> > and programs like symify to walk backwards up the callstack.

> Does this then mean that program's compiled with the
> -fomit-frame-pointer option, that access local variables directly
> relative to %esp can yield problems with symify?

I'ld think so, yes. A quote from the gcc docs:

`-fomit-frame-pointer'
     Don't keep the frame pointer in a register for functions that
     don't need one.  This avoids the instructions to save, set up and
     restore frame pointers; it also makes an extra register available
     in many functions.  *It also makes debugging impossible on some
     machines.*

Actually, you normally won't get a sensible traceback on the screen,
so there's nothing left for symify to work on. In
'-fomit-frame-pointer' mode, only the function itself knows how many
local arguments and local variables it has on the stack at each point
in time, so it's next to impossible to find out where the traceback
should begin. I'd not even bet on gdb to be able to find the traceback
in code without a frame pointer without human aid.

HBB

- Raw text -