rtems gcc 4.6.1 can not compile stop at check TLS
ralf.corsepius at rtems.org
Mon Aug 29 11:54:40 CDT 2011
On 08/29/2011 05:47 PM, Sebastien Bourdeauducq wrote:
> On Wed, 2011-08-24 at 16:26 +0200, Ralf Corsepius wrote:
>> I regret having to say so, my feel about this patch is "short-sighted
>> featuritis", blowing up the toolchain beyond reason.
> This patch actually _decreases_ software bloat where it matters, namely
> on the embedded system targeted by RTEMS. Using software emulation of
> the divider (or the other CPU features we want multilibs for) when the
> hardware divider is available only makes code slower and larger. Newlib
> does make use of these features.
Adding multilibs needs to be carefully balanced and compromises to be
taken. i.e. on one hand, toolchain implementors need to find balanced
compromises between "speed", "size", "number of multilibs" and "number
of users", on the other hand, users need to learn to live with
It's the same, what you do when using a mainstream OS - You are using
binaries which have been compiled by a setup to support a "main-stream"
target audience, which means it, is using a compromise between several
Simply adding a mulitlib for each and every flag a compiler supports
simply not useful - Think about the zoo of cpu variants/instruction-set
variants the i?86 cpu-family consists of. It's simply unmanageable to
implement a multilib for each of them, nor is it useful, because most of
these variants would only provide microscopic gains.
> If you do not want too many multilibs (which aren't much of a problem
> given the cost of mainstream CPUs and storage those days) just build one
> lib with all the CPU options enabled. This is what we (the Milkymist
> project) implement, and we are by far the largest user of the LM32
> target (the only other LM32 BSP, lm32_evr, is - by the words of its
> developer - "not really used yet for anything serious"). Currently, we
> cannot use your LM32 toolchain binaries because they lack this feature
> we need. What is the point of shipping software that almost no one uses?
> This multilib patch is upstream GCC already.
ROTFL, implemented, submitted and commited by you!
If gcc-4.6.1 would build (which it, as I told you several times before,
it doesn't), I likely already would have implemented custom multilibs
for lm32-rtems (Which is what we already do for many targets), which
likely would revert this change.
> In a nutshell: just build the libraries with all the CPU options enabled
> into the LM32 RTEMS toolchain. It is the right thing to do.
This is the first time I am hearing this-Patch proposals welcome.
More information about the rtems-users