From mint-bounce@lists.fishpool.fi Wed Feb 20 18:33:01 2008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=dLU8zQeWtkBtL22CXkdWAn6CN3QaMOClsDc0XfNrPmU=; b=txUcUzKIddXme0WwBp/gNrCRp1xzfzhEeiwSPhS03sVewtwmSt7rrarC2t/rZNL0JhyRGCXoq5wXFRxyU/k510/QK5fFpEifngi2UniR/CWWRiYhkbqrNeZEYxRFfTxkXbhM64LigHQT5dn01SWKRDxiIDFwdTwIP692ZV/naI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gi+CQk1S4v1q9m0DAGBHbiMM7WYT+w2Gm8mXD4WvWtm8tOMnfWxdfaoqy5xoxUZV+YTSqSF0yoWlPe0Hph9uH2moPZfVOBy5RCkXe0J6c/ANXPXNicOi+RYld0UmRCRrK4w52PcXHDMvArF6AdrsgQsL5EwCg7amjGMlGsarpHg= Message-ID: <47BCB5C8.1020001@gmail.com> Date: Thu, 21 Feb 2008 00:20:40 +0100 From: Miro Kropacek Organization: Mystic Bytes User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Alan Hourihane CC: mint@fishpool.com Subject: Re: [MiNT] Some mintlib patches References: <47BC986B.7050704@gmail.com> <1203548195.11227.12.camel@localhost> In-Reply-To: <1203548195.11227.12.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: miro.kropacek@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: > I'd really like to know what the real problem is here, this just seems > like another bandage for a real problem. > > For me I've actually reverted your original patch to crt0.S and I don't > see a problem. So it'd be worth finding out if you reverted the file > back to the original and find out why gcc is crashing (if it really > still does). > > It's quite tricky. The problem appears when you have low TPA (let's say 1024 KB) and big stack (let's say 256/512 KB). In gcc compilation, in some (hard to say if deterministic) cases some compiled binary would like to say "Fatal memory bla bla" but instead of this crashes (trap call wants to put some stuff on stack but stack is corrupted somehow). If you remember my early posts about gcc4 compilation (unable to use -O2 with some big files), this is exactly the case -- gcc should never crash, it should write Fatal error message. This is quote from my mail: --- I'm not sure exactly why but I think it has something to do with that value used as initial (early) stack -- it's set as (p_hitpa & 0xfffffffe) where p_hitpa should be upper boundary of free process memory + 1 byte. I think one of the possible explanations (why program sometimes crashed and sometimes shows the message) is there's something wrong with that early stack -- for example, when p_hitpa = 0x2000, 0x2000 & 0xfffffffe = still 0x2000 and we're one byte beyond the allowed area. However, I was too tired/lazy to track it into kernel (if it reaches kernel syscall or it just crash in trap handler) so I'm not 100% sure about it. But this changing behaviour (bus error vs message) occurs when I add code/variables to C source -- i.e. BSS could get bigger/smaller i.e. odd/even in length. --- But I never actually went deeper than this speculation since I wanted to see gcc4 so much :) So if you ask about reproducibility, install aranym, easymint, unpack&patch gcc-4.2.3, configure/make bootstrap and you'll see the crash. > Then don't change it so often :-) > > Haha, when you need to experiment (like spotting bug above) you'll welcome this ;) -- MiKRO / Mystic Bytes http://mikro.atari.org