This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Cygwin libs broken by "-fomit-frame-pointer" switch


On Tue, May 01, 2001 at 08:46:46AM +1000, Robert Collins wrote:
>IIRC you are breaking fork. We have to work around win32's brokenness.

Actually you are definitely breaking signal handling.  Maybe fork, too,
the fork error doesn't mean that fork is broken as much as one of the
initialization routines that fork calls may be broken.

The reason that -fomit-frame-pointer is not part of the Makefile is that
it doesn't work.  Cygwin doesn't build with it.

It is possible to build certain modules with this option but it is very
picky and subject to change.  IMO, it isn't worth the effort.

cgf

>---- Original Message -----
>From: <steve.snyder@philips.com>
>To: <cygwin@cygwin.com>
>Sent: Tuesday, May 01, 2001 8:47 AM
>Subject: Cygwin libs broken by "-fomit-frame-pointer" switch
>
>
>Hello.
>
>I have noticed that building the Cygwin libraries with the
>"-fomit-frame-pointer" compiler switch breaks the libraries.  No errors
>are seen in compiling/linking, but an attempt to use a program that
>relies
>on the library (bash, for instance) always causes a stack fault.  This
>is
>with v1.3.1-1 of the Cygwin code and v2.95.3-4 of the compiler.
>
>(Some background for those who don't know what I'm talking about: By
>default GCC dedicates one of the precious few x86 registers, EBP, as a
>base pointer for local variables.  However the stack pointer, ESP, can
>just as easily be used for this task, freeing EBP for other uses.  The
>"-fomit-frame-pointer" switch tells the compiler to do just that.)
>
>The error always looks similar.  Here is an attempt to use sh.exe:
>
>  handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
>  stackdump: Dumping stack trace to sh.exe.stackdump
>  sync_with_child: child 151(0x6C) died before initialization with
>status code 0xC0000005
>  sync_with_child: *** child state waiting for longjmp
>
>Then the dump itself:
>
>  Exception: STATUS_ACCESS_VIOLATION at eip=610245E3
>  eax=00000001 ebx=FFFFFFFF ecx=6108E74C edx=02A50000 esi=0A011304
>edi=00000000
>  ebp=0241F614 esp=0241F8BC program=C:\unix\bin\sh.exe
>  cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
>  Stack trace:
>  Frame     Function  Args
>  0241F614  610245E3  (00000000, 00000000, 00000000, 00000000)
>  0241FA34  610245E3  (00000000, 0241FA34, 77F6CD00, 0241FD9C)
>  02420000  02423348  (EEFFEEFF, 00000002, 00000000, 0000FE00)
>    31464 [main] sh 294 handle_exceptions: Exception:
>STATUS_ACCESS_VIOLATION
>    32081 [main] sh 294 handle_exceptions: Error while dumping state
>(probably corrupted stack)
>
>Does the Cygwin Unix-on-Win32 code depend on a frame pointer distinct
>from the stack pointer, or is this a bug?

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]