Re: crt0.o from newlib has ARM32-only routines when building gcc for arm-eabi

[David Fernandez <david dot fernandez dot work at googlemail dot com>]

On Tue, Jun 19, 2012 at 6:11 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Jun 19, 2012 at 10:06 AM, David Fernandez
> <david.fernandez.work@googlemail.com> wrote:
>> On Tue, Jun 19, 2012 at 3:17 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Tue, Jun 19, 2012 at 6:15 AM, David Fernandez
>>> <david.fernandez.work@googlemail.com> wrote:
>>>> unimplemented: Thumb-1 hard-float VFP ABI
>>>
>>> --with-cpu=cortex-m3
>>
>> That was the problem! (no need to add --disable-decimal-float, which
>> is disabled by default on arm targets). Thanks very much!
>>
>> I guess this poses a few questions:
>>
>> Should there be several crt0.o files available, that gcc should pick
>> depending on the -mthumb, -march, and -mcpu?
>>
>
> mthumb means either thumb1 or thumb2 depending on -mcpu
> so newlib has to ?be told that
>
>> Is it that gcc is not quite there yet, or that newlib is not yet
>> compatible enough with the gcc multilib build system?
>>
>> Any gcc guru knows something about this? As otherwise, the --target
>> configuration option does not produce a compiler supporting all the
>> cpus and architectures that the target covers in theory, and then
>> perhaps there should be a default prefix/suffix for the executables
>> and folders depending on the --with-cpu and/or --with-arch...
>>
>> Cheers

I don't deny that newlib needs to be compiled per cpu... I'm just
guessing here that the standard libc would work with any cpu and mode
covered by the selected target, while, with newlib, we have to
recompile the whole gcc with different options for the same target to
support all the cpus in that target.

I guess that another options is: Shouldn't we be splitting the
arm-eabi target on subsets of compatible cpus, like
--target=arm-eabi-cortex-m3, etc.?

--
For unsubscribe information see http://sourceware.org/lists.html#faq