Re: [MiNT] mintlib release

[Alan Hourihane <alanh@fairlite.demon.co.uk>]

On Sun, 2008-04-27 at 18:09 +0200, Miro Kropacek wrote:
> > 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.
> >
> > 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.
> >
> this is not exactly true. i reviewed all mails from that time (funny 
> reading ;) and it happened in this way:
> 
> - 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.

I think this needs to be proved with a repeatable test case. 

> - 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.

No, it is not harmless. It broke things for me & Keith.

> 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)

No CVS mintlib does not work for me without reverting the startup/crt0.S
fix.

Alan.