From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Sun, 12 Jul 2009 18:12:11 +0200 Subject: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file In-Reply-To: <20090712155024.52BC9832E416@gemini.denx.de> References: <1247081808-31514-1-git-send-email-plagnioj@jcrosoft.com> <1247135043-3494-1-git-send-email-plagnioj@jcrosoft.com> <4A5996A4.7030506@googlemail.com> <200907121002.46516.sr@denx.de> <20090712102932.6247D832E416@gemini.denx.de> <20090712120655.GA21713@game.jcrosoft.org> <20090712143607.8A901832E416@gemini.denx.de> <4A59F95A.6060803@googlemail.com> <20090712155024.52BC9832E416@gemini.denx.de> Message-ID: <4A5A0B5B.2010408@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Wolfgang, Wolfgang Denk wrote: > Dear Dirk, > > In message <4A59F95A.6060803@googlemail.com> you wrote: >>> I really hesitate to do that. It seems that not using the compiler >>> provided library is not such a clever thing to do. The compile writes >>> probably know better what a specific version of GCC needs that >>> anybody else. >> Yes, you are basically right. But ;) >> >> But, as Jean-Christophe mentioned above, it's a pain with the various >> ARM tool chains floating around. Some are older, some are newer, some >> are configured for EABI, some not, some are configured for software >> floating point, some for hardware floating point, etc., etc. > > Right. And each of these is supposed to come with it's own version of > libgcc, configured exactly for the requirements of this specific > version and configuration of GCC. > > And it turns out that the majority of architectures works just fine > with such a setup, just using libgcc for functions required for and > provided by the compiler. > > If the compiler provided functions cannot be used, this is IMO an > indication of a broken toolchain, which should either be fixed (if > it's under some form of maintenance) or abandoned (because you will > have the same problems again in other situations outside of U-Boot). > >> While I as developer might be able to find a recent tool chain with a >> libgcc compatible with U-Boot, I think we should avoid this pain for >> our users. Users which like to "just compile U-Boot" and then we tell >> them "well, your tool chain you seem to be happy with doesn't link >> U-Boot, for U-Boot you have to install an other one" I think wouldn't >> make them happy. > >>>From the technical point of view it is only reasonable to point out > that these users have a broken toolchain, and that they should take > the first opportunity to fix or replace it. > > Of course it it nice if we can also provide a workaround for them, so > they can update at a point in time that is convenient to them. But the > implementation of such a workaround should be clean, and eventually be > used only for systems that really need it. > > In no case we should make the use of such a workaround for broken > setups the rule which has to be used by all systems (and eventually > all architectures, even those that never had such problems in the > first place). Ah, I understand, most probably we are not aligned about what we talk, sorry. Yes, I know, there was some discussion about the Makefiles and that there are some requests to change them. Unfortunately, I'm no Makefile expert. So I'm only talking about ARM systems/architecture. If the Makefiles discussed previously touch other systems/architectures, too, then this is not what I'm talking about. > This is why I really hesitate to apply these patches - they make the > workaround for a few broken systems the rule, instead of making clear > that this is an exception needed only by some (broken) systems. For me the broken systems are in a first step ARM tool chains. Nothing more. Not sure if we can limit it to a sub-group of ARM systems, though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC? >> Regarding not using the compilers library and if this clever: No, it >> isn't clever, you are right again. The compiler's library version is >> most probably better optimized. But, we are dealing with a boot loader > > This is in no way a question of optimization. If we provide > replacements for the libgcc functions, _we_ will have to maintain > these and make sure they work correctly with all versions of GCC that > exist in the multiverse and with all of their possible and impossible > configurations. It was my understanding that Jean-Christophe copied this code from kernel? Like we do with some other systems, e.g. MTD? So it's maintained by kernel developers? Sorry if I missed something here. > That's a lot of work we put on ouw own back for - for > what? > >> here. So for the topic we discuss here, I think avoiding some pain for >> us ("my tool chain doesn't compile U-Boot, help!" mails at this list) >> and our users (see above) is the stronger argument than some >> optimization/performance issues in some (seldom?) used math functions. > > I think that answering a few mails, pointing out known problems with > broken tool chains requires by far less amount of effort than adding > this code. Heck, discussing and testing of this patch took already > way more of my time than replying to all related messages in the last > 3 years together... > > > I think the patch needs to be changed such that it needs to be > specifically enabled for broken tool chains, and that by default all > systems behave the same, i. e. assume a working tool chain and use > libgcc. Yes. I talk about "broken tool chains == ARM tool chains". Nothing more. If the Makefile changes in the patches we talk about do some more, then that's not what I mean. Best regards Dirk