At first, MiKRO experienced crashes (before main ?) when running programs using nearly all the available TPA memory. So he added a nice message, and he increased the size of the preliminary stack.this is not exactly true. i reviewed all mails from that time (funny reading ;) and it happened in this way:Then Keith experienced problems of corruption of very long command lines (more than 2Ko) on ar or ld. I seems that the MiNTLib startup code use more or less the same memory area for the preliminary stack and the parsing of the command line.Keith and Alan reverted MiKRO's patch, and everything went OK again.
- i had some crashes with gcc compilation. we managed to find it's the low stack (which can be set using "stack" command) so I set 64 KB (in cvs, 2048 KB for my gcc build) as default stksize since the original one was about 24 KB. But I was really angry why I can't do this with "stack --fix=2048KB" (binary crashes then)... reason was:
- my TPA was too low. but instead of showing me message "insufficient memory, fatal error" binaries crashed sometimes. *this* is our problem we need to track down -- why area between hitpa and end of bss wasn't enough. my guess was (and still is) there was faulty code for aligning that hitpa (bclr #0 with address +1 byte more than hitpa really was)
- since we were in hurry, i decided not to track down if my problem is here and i set our stack explicitly as 1 KB which fixed my problem (i've finally seen that error message every time then)
- this is a version which Alan tried and didn't like it very much since it crashed for long command lines so he reverted it back (same for Keith -- both of them have never problems with low TPA so they never spotted crash as I did)
- however, I managed to reproduce similar problem with 'ar' when I compiled "merged" build binutils+gcc... I found the problem is in that explicit 1 KB stack -- I set it as 64 KB and finally, all problems were gone.
- this is also current state in cvs mintlib (64 KB preliminary stack) so it's harmless but yes, we don't know the original source of problem.
So, to summarize it: the current cvs mintlib is working, you should be able to do gcc/binutils bootstrap with only changes to stksize (or even without this if you're not doing bootstrap) and there's really no need to revert anything. however, if we want to use 100% safe method (preliminary stack as big as possible and not 64 KB), we need to track down that error in original code. But if we are lazy ;) we don't need to anything, it's true it's hack but it's working and it's clear when something will go bad, the problem is in low preliminary stack (but I really can't imagine >64KB command line)
-- MiKRO / Mystic Bytes http://mikro.atari.org