From mint-bounce@lists.fishpool.fi Tue Sep 6 20:03:41 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: [MiNT] Binutils FIXED! From: Mark Duckworth To: Mint List Content-Type: text/plain Date: Tue, 06 Sep 2005 13:57:26 -0400 Message-Id: <1126029452.18656.37.camel@mduckworth.phillypark.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.1.fc4.nr) Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Hey guys, I've gotten to the bottom of every binutils issue. To start, there was no bug in nm, the symbol tables were corrupt with the s/rawsize/size/g patch. This is incorrect. rawsize was initialized and set, and is right, however the "sanity check" portion must then be commented out as it makes no sense at all. It compares an address to a size (like in bytes). If you comment this out, the compiled code is quite correct. Once things are changed back to rawsize as in the original binutils patch things are quite correct. As far as the memory allocation issue was concerned, it was as was expected, my code was allocating ST-ram. This seems a little counterintuitive though. If MiNT runs out of ST-ram, the program should attempt to use fast ram or vice versa I think, or there should be a flag that says you can do this. The new binutils is not setting flags properly. Binaries from old binutils resulted in flags: Current flags: 0x00000007. Binaries from the new binutils resulted in flags 0x00000000. The current behavior of the flags tool is either incorrect or misunderstood by me. There are two flags, fast ram and fast alloc. Setting fast-ram without fast alloc causes the resulting binary to continue to use ST-ram anyway. This is not immediately obvious at all. Maybe the dev who knows the inner workings of the ram knows that you must have fast alloc in order to use fast ram, but I didn't, thus when you set fast ram, it should pull in fast alloc automatically IMHO. So to summarize, the problem with binutils was that flags were nnot being set to matching binutils 2.13. They need to be fast ram, fast alloc, fast load, and protected mem by default, and they're not for some reason (yet... I'll fix that!). And the rawsize to size change was completely misguided and incorrect. Once I get it all fixed up, I'll compile a new rpm and distribute it. This time I'm going to test it pretty hard though so what is released should be considered correct. Thanks, Mark