Dear Dirk Behme,
In message 4A5A0B5B.2010408@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.
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?
We should always assume to have a usable toolchain first, and only fall back on the workaround if it's really necessary - no matter if it's ARM or anything else.
Binding this to ARM is IMHO inherently wrong.
Best regards,
Wolfgang Denk