Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: steve DOT snyder AT philips DOT com To: Cc: Subject: Re: Cygwin libs broken by "-fomit-frame-pointer" switch Message-ID: <0056910011738862000002L122*@MHS> Date: Mon, 30 Apr 2001 18:00:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 04/30/01 17:57:57" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id TAA20524 Hi, Rob. Does the prohibition against "-fomit-frame-pointer" apply to all binaries build for the Cygwin environment, or is it just a problem for cygwin1.dll? Thanks for the response. robert DOT collins AT itdomain DOT com DOT au on 04/30/2001 03:52:34 PM To: cygwin AT cygwin DOT com@SMTP Steve Snyder/SVL/SC/PHILIPS AT AMEC cc: Subject: Re: Cygwin libs broken by "-fomit-frame-pointer" switch Classification: IIRC you are breaking fork. We have to work around win32's brokenness. Rob ---- Original Message ----- From: To: 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? Thanks. -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple