Hi again, > > One thing is still mystery for me -- why under aranym with JIT and > > without mmu mintlib says (right) message "Fatal error: insufficient > > memory" (with default TPA in mint.cnf) but under falcon+mmu it says > > "bus error" (or memory violation, I don't remember now). > > You're right, the only mystery is here. > mystery is semi-solved :) I tested it more deeply, it fails on gemdos calls! (i.e. showing message about memory and pterm). 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 lenght. I attach patch which use more clean / clear way, we set explicitely 1 KB stack (minus basepage length) and use this one instead of very top of memory. P.S. gcc4 just reached stage2, our "friend" regex.c compiled like a charm! I'm really curious what I'm going to find next morning ;) P.P.S. someone with write access to cvs should really commit all those patches, I'm going to lose in them -- esp. when someone says "this patch is bad, use this one" 3 weeks ago ;-) -- MiKRO / Mystic Bytes http://mikro.atari.org
Attachment:
crt0.patch
Description: Binary data
Attachment:
crtinit.patch
Description: Binary data