bunnell@henry.asel.udel.edu (Tim Bunnell) (02/23/90)
To my considerable surprise, under 1.5.3 the command: ar q libc.a 'lorder *.s | tsort' gives every appearance of actually working. However, it reports a cycle between malloc and memmove (the assembly version which also contains an entry point to memcpy). I have not been able to manually trace the cycle, but in trying to do so I noticed that malloc has DEBUG code enabled. Is this the recommended setting for that routine at present? Will anything break if the debugging code is disabled? By the way, apart from already reported problems and some errors that were probably my own the 1.5.0 --> 1.5.3 upgrade has gone smoothly for the commands and libraries. Are we to rebuild the boot image and kernel using the old kernel + new fs-mm-tools, or wait for the new kernel before taking that step? Tim Bunnell <bunnell@asel.udel.edu>
ast@cs.vu.nl (Andy Tanenbaum) (02/23/90)
In article <11884@nigel.udel.EDU> bunnell@henry.asel.udel.edu (Tim Bunnell) writes: >To my considerable surprise, under 1.5.3 the command: > > ar q libc.a 'lorder *.s | tsort' > I cheated. tsort is a wholly new program, unrelated to the old one. > Are we to rebuild the boot image and kernel using >the old kernel + new fs-mm-tools, or wait for the new kernel before taking >that step? Rebuild using the new fs, new mm, new tools and old kernel. The new kernel will follow soon. I am already busy with 1.5.4. Fortunately it is definitely converging. The differences between 1.5.4 and 1.5.3 so far are all very small bug fixes. Andy Tanenbaum (ast@cs.vu.nl)
evans@ditsyda.oz (Bruce Evans) (02/25/90)
In article <11884@nigel.udel.EDU> bunnell@henry.asel.udel.edu (Tim Bunnell) writes: | ar q libc.a 'lorder *.s | tsort' | |gives every appearance of actually working. However, it reports a cycle |between malloc and memmove (the assembly version which also contains I saw this in 1.5.0 too. It appears to be a bug in lorder. |but in trying to do so I noticed that malloc has DEBUG code enabled. Is this |the recommended setting for that routine at present? Will anything break if |the debugging code is disabled? I think the routine is well enough debugged by now. I have seen the "assertion failed" message from it a few times, but it was always from a bad argument to free or the stack being too small. Someone should test how much time the extra tests costs. If not much, leave the tests in, but don't call them DEBUG code. |commands and libraries. Are we to rebuild the boot image and kernel using |the old kernel + new fs-mm-tools, or wait for the new kernel before taking |that step? Use the old one. -- Bruce Evans evans@ditsyda.oz.au