From: SourceForge.net <no...@so...> - 2005-03-27 00:47:53
|
Bugs item #1170212, was opened at 2005-03-24 16:15 Message generated for change (Comment added) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1170212&group_id=599 Category: C-Front End Group: None Status: Open Resolution: None Priority: 7 Submitted By: Hubert Sack (hsack) Assigned to: Erik Petrich (epetrich) Summary: Compiling SDCC from cvs checkout causes SIGSEGV Initial Comment: I can't compile SDCC from the lastest (03/24/05) snapshot under Cygwin (other environments not available to me). Running make results in SIGSEGV as make tries to compile the lib by using the compiled SDCC (no errors while it's compile) I attached the output (in a textfile) ---------------------------------------------------------------------- >Comment By: Erik Petrich (epetrich) Date: 2005-03-26 18:47 Message: Logged In: YES user_id=635249 I just downloaded Cygwin and installed it on a Windows 2000 system. So far I've been able to successfully build 2.4.8 #285 and 2.4.8 #283, both as a Cygwin app as well as MINGW32. Since I can't reproduce this yet myself, what would be helpful is to edit the device/lib/Makefile and remove _schar2fs.c (the source file being compiled during the SIGSEGV) from the SOURCES macro and rerun the make. From your output, it appears that it successfully compiled some files, so probably it will be able to compile a few more before faulting on another. Just keep removing them from the SOURCES macro. You don't have to exhaustively test every library source file, but it would be helpful to have a few more examples of successes and failures so that we might find a pattern. ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-26 06:34 Message: Logged In: YES user_id=1160854 The SIGSEGV problem still exists in current version (2.4.8 #984). I've done a full and fresh checkout... The attached file is a textfile with a screencopy ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-26 04:36 Message: Logged In: YES user_id=1160854 Sorry! The verion I used was 2.4.8 #983 *not* #980, as I wrote... ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-26 04:34 Message: Logged In: YES user_id=1160854 Yesterday (03/25/2005) I tried to find the reason of the "signal 11: SIGSEGV", but it's very difficult to find anything. Starting SDCC by the debugger GDB result in success (I tried *not* only once... So I put some "control point output" via printf into the source and detected in the first step that the SIGSEGV was raised within "emitRegularMaps". Than I took a closer look to the problem and found "iCode2eBBlock" called from "iCodeBreakDown" raising the signal. That's strang because the sourcecode of this function was not changed since 2.4.8 #977, which workes fine. Everything is done using Cygwin environment and with the lastest source (2.4.8 #980). I belief the problem must be some stages earlier. If can can do any support (tests, control outputs etc.) to solve the problem, please let me know. ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-24 16:28 Message: Logged In: YES user_id=1160854 Sorry! The version 977 is o.k. I'm using it for now, it's the snapshot of 03/19/05. The correct version causing the SIGSEGV is: $ ./sdcc -v SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds40 0/hc08 2.4.8 #983 (Mar 24 2005) (MINGW32) ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-24 16:21 Message: Logged In: YES user_id=1160854 $ ./sdcc -v SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds40 0/hc08 2.4.8 #977 (Mar 24 2005) (MINGW32) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1170212&group_id=599 |