On 20:17 Sun 12 Jul , Wolfgang Denk wrote: > Dear Dirk Behme, > > In message <4a5a0b5b.2010...@googlemail.com> you wrote: > > > > > 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. > > Note that this is not a question of ARM versus other architectures. > On ARM the use of libgcc should be the default like on all other > architectures - only if needed it should be possible to switch on a > don't-use-libgcc mode, but this should then be independent of > architecture, either. which is the case no arch are force to switch the current patch just allow to switch to this mode. > > > > 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? > > That would be a board specific thing, which is inappropriate, as it > does not depend on a specific board. The selection could be done by > passing some argument or environment variables to "make", though. > > > > 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. > > Even if it's maintained in Linux, we still have to follow any changes > there, and port these to U-Boot, and analyse each new problem popping > up by future uses of C statements that cause GCC to generate libgcc > calls - that may or may not be covered by the kernel provided code. > > No matter where we get the code from, an ongoing effort will be > needed to maintain this. > > > Yes. I talk about "broken tool chains == ARM tool chains". Nothing > > This is where I disagree. Why should we automatically assume that > there are no sane ARM toolchains? unfortunately most of the arm toolchains are not sane for every point of view as you can not build U-Boot, kernel and userland with the same optimized toolchain most of the time.
Maybe oneday we can assume that we could use any arm toolchain to build the 3, but for now I can assure it's not the case. On other it maybe not the case but as example on mips we have similar issue to workaround to be able to build U-Boot & Kernel Best Regards, J. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
