-mfloat-abi=softfp

[ng@piments.com]

On 04/27/10 15:21, Martin Guy wrote:
> On 4/27/10, ng@piments.com<ng@piments.com>  wrote:
>>   Uptil now I was using -march=armv4t , setting it ep9312 fails on 4.2.4
>>
>>
>>   [ALL  ]
>> /back/ts/ct-ng/targets/src/gcc-4.2.4/gcc/crtstuff.c:1:
>> warning: target CPU does not support interworking
>>   [ALL  ]    Assembler messages:
>>   [ALL  ]    Error: unknown architecture `ep9312'
>>   [ALL  ]
>>   [ALL  ]    Error: unrecognized option -march=ep9312
>
> THat's not GCC. That's the assembler (binutils).

Thanks , I've just got your email about comsic rays ;)

I'd already realised that part of the reason for the seg fauilts looks 
like it was hardware instability. I ran some stress tests (other than 
ct-ng :P ) and it tripped out as well.

I've lowered the system clock and that seems to have stabilised it for 
now , until I have time to strip it down.

However, I did still have _repeatable_ seg faults as I reported in an 
earlier post.

> Yeah, this whole area is a pain.  Can you drop the empty -march switch
> and use -mcpu-ep9312? That's the only combinatin that seems to work
> with GCC and the assembler


That's it !

I dropped all use of -march and only use ep9312 rather than armv4t

  LIBC_GLIBC_EXTRA_CFLAGS=-mfpu=maverick -mfloat-abi=softfp  -mcpu=ep9312
CT_ARCH_CPU = ep9312

I had to move to starce-4.5.19 as well because of headers. I now have 
managed to configure ct-ng to build a nice new crunchy toolchain.

It remains to see if it can produce useful code....

thanks again for your help and guidance.

best regards.


>
>>   Could this relate to the -march= switch message I was getting before. Is
>> some other stage deciding this is invalid and replacing it with a null
>> string?
>
> If ther is an empty -march or -march=armv4t it's probably best not to
> have *any* -march flag. You may have to hack crosstool-ng to achieve
> this, I don't know.
>
>     M
>









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