CC of reply to bootldr discussion thread. Nick Bane -------- Original Message -------- Subject: Re: balloon bootldr gcc 3 considerations Date: Fri, 10 Mar 2006 11:23:33 +0000 From: Nick Bane To: Colin Tuckley CC: Wookey , David Bisset , Chris Jones , Steve Wiseman References: <440EFB52.9080807@tuckley.org> <440EFE2A.9010404@cecomputing.co.uk> <440F1348.2090108@tuckley.org> <440F3074.1010309@cecomputing.co.uk> <440F38E4.8010908@tuckley.org> <440F47A6.7080903@cecomputing.co.uk> <440FF459.1040807@tuckley.org> <44102564.4060606@cecomputing.co.uk> <44113A43.5050008@tuckley.org> Colin Tuckley wrote: > I spent quite a bit of time yesterday working out what was going on when > using gcc 3.3 to compile bootldr. > > Since this has ramifications for Balloon 3 can I ask all 4 of you to please > comment on the things below. > > 1) I'm going to be doing a major clean up of the bootldr code at some point > in the future and if I don't hear anything I'm going to remove pretty much > *everything* that is not used or explicitly to do with Balloons. > Oh dear. I pushed yaffs patches back to Handhelds and they have been good enough to make that part of the official bootldr code. Do we really want to fork bootldr development? My preference would be to add config options to isolate unneeded code. If handhelds do continue bootldr development (extending CF socket usage and maybe pxa270 usb console usage) then to strip out their work might be a wrong way of cooperating. I am generally against such a fork unless there is some policy of avoiding Handhelds. I would prefer to act with Handhelds and donate a balloon3 to them for inclusion in their efforts. > 2) After working through all the various options used in the Makefile the > following has come to light: > > a) -UBOOT_SILENT gets added to the compiler options. A grep for this shows > that it is only referenced once in boot-sa1100.s so why is it *unset* when > we never set it? or is this just a hangover from something which got > removed. There are other options in a similar situation what should we do in > the general case? > No idea. Looks like a cleanup candidate. My guess is that it was probably related to the squelch_serial stuff. > b) -mshort-load-words is set, this is a deprecated alias for > -mno-alignment-traps which does nothing on ARMv4 and later processors, I've > removed it. > That was crucial for the initial 2.95 to work for reasons that no one seemed to understand. You may be right that it is deprecated but I would like someone to ratify this choice assuming that we want backwards compatability with 2.95 unless it was deprecated there too. > c) both -fPIC and -fpic were being added to the options for CC, these do > subtly different things, which should we be using? not both since they > actually conflict I think. > I have no idea. Looks like more confusion. Do clean that one up. Might that even be related to the gcc 2.95/3.3 conflict? > 3) This is probably the most important one, my problems with odd-ball things > happening due to initialised variables not getting set appear to be due to > the different optimisations done by gcc 2.95 and gcc 3.3 when the -O (-O1) > option is set. > That is remarkable. For future work it may be very helpful to understand why gcc 3.3 superficially seems to screw up else we could spend px270 time chasing mirages. > If I set -O0 (optimisation off) then things work properly. I'm still > investigating whats actually happening, but so far it looks like gcc 3.3 > includes a lot more optimisation at level 1. The man page mentions 18 flags > that get turned on in gcc 3.3 at level 1 vs only 4 in gcc 2.95 > > Is it worth trying to find out which flag is causing the problem and then > trying to find and fix the bit of code or turn that option off individually? > Or should we just run bootldr with no optimisation? > This is a very good point. I think we should definitely start with understanding the problem and fixing any rogue code. I was involved in part of a port of some C code in Sweden a while back where they said that their code wouldn't "optimise". It turned out that an assembler patch of theirs was using a register that was involved in optimisation under gcc but not with the M$ WinCE compilers as I discovered by careful inspection. In 1/2 day I speeded up their time-critical code by 400% with that scrat of information. I know that there were certain assembler options that were useless (for obscure reasons) with optimisations > regards, > > Colin >