From mboxrd@z Thu Jan 1 00:00:00 1970 From: downing.nick@gmail.com (Nick Downing) Date: Tue, 28 Feb 2017 01:50:55 +1100 Subject: [TUHS] Emacs and undump In-Reply-To: <20170227143302.GA15427@cowbell.employees.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> <20170227143302.GA15427@cowbell.employees.org> Message-ID: Thanks for the stak.c it's a good idea. I'm not sure about the stack freeing routine at the end of the file as it seems to rely on a bit of pointer voodoo but I think I could rationalize all that. cheers, Nick On Feb 28, 2017 1:33 AM, "Derek Fawcus" wrote: > On Mon, Feb 27, 2017 at 07:12:09PM +1100, Nick Downing wrote: > > I've been having a bit of trouble with /bin/sh (Bourne's original one) > > for the same reason. > [snip] > > Trouble is, this makes a non-stdio-using program be > > stdio-using, in the worst case it's a non-stdio-using program that has > > its own malloc() based on sbrk()... so we get another malloc() > > happening in the middle, I temporarily fixed this by redirecting the > > modern system's malloc() into the ancient system's malloc() but this > > is a very non desirable solution. As another possibility I was > > thinking of changing the ancient system's sbrk() into realloc() and > > implementing a routine to relocate the heap, it obviously would have > > to understand everything on the heap and everything that can point > > into it. > > How about applying Geoff Collyer's change to the shell memory management > routine available here: > > http://www.collyer.net/who/geoff/stak.port.c > > DF > -------------- next part -------------- An HTML attachment was scrubbed... URL: