-mfloat-abi=softfp

-mfloat-abi=softfp

[ng]

Hi,

I am experimenting with building a toolchain with maverick enabled based 
on patching gcc according to Martin Guy's patch set. 
http://martinwguy.co.uk/martin/crunch/

He suggests using -mfpu=maverick -mfloat-abi=softfp

I am having difficulty locating this in ct-ng menuconfig. There is HW or 
SW option but help does not say what switches this actually corresponds 
to. I suspect it is something other than -mfloat-abi so should I supply 
this as an extra CFLAG ?

Some more explicit help comment on this option would be good. Most 
options are quite specifically documented as to what they correspond to.

Thanks for any clarifications.

Best regards, Peter.

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

Re: -mfloat-abi=softfp

[Martin Guy]

On 4/18/10, ng@piments.com <ng@piments.com> wrote:
>  I am experimenting with building a toolchain with maverick enabled based on
> patching gcc according to Martin Guy's patch set.
> http://martinwguy.co.uk/martin/crunch/
>
>  He suggests using -mfpu=maverick -mfloat-abi=softfp
>
>  I am having difficulty locating this in ct-ng menuconfig. There is HW or SW
> option but help does not say what switches this actually corresponds to. I
> suspect it is something other than -mfloat-abi so should I supply this as an
> extra CFLAG ?

Those are flags that need to be passed to the new gcc that you build,
when it is run to generate ARM/Maverick code. As far as ct-ng is
concerned, assuming you're building a usual cross-compiler, they would
need to be used while cross-compiling the C library that will be used
on the target system - that is the option you need to locate; it'll
probably be called LIBCFLAGS or something like that;

     M

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

Re: -mfloat-abi=softfp

[ng]

On 04/18/10 20:58, Martin Guy wrote:
> On 4/18/10, ng@piments.com<ng@piments.com>  wrote:
>>   I am experimenting with building a toolchain with maverick enabled based on
>> patching gcc according to Martin Guy's patch set.
>> http://martinwguy.co.uk/martin/crunch/
>>
>>   He suggests using -mfpu=maverick -mfloat-abi=softfp
>>
>>   I am having difficulty locating this in ct-ng menuconfig. There is HW or SW
>> option but help does not say what switches this actually corresponds to. I
>> suspect it is something other than -mfloat-abi so should I supply this as an
>> extra CFLAG ?
>
> Those are flags that need to be passed to the new gcc that you build,
> when it is run to generate ARM/Maverick code. As far as ct-ng is
> concerned, assuming you're building a usual cross-compiler, they would
> need to be used while cross-compiling the C library that will be used
> on the target system - that is the option you need to locate; it'll
> probably be called LIBCFLAGS or something like that;
>
>       M
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
>

Hi Martin,

thanks for the help.

  CT_LIBC_EXTRA_CC_ARGS: 

  Extra flags to pass gcc when building.
  Seldom used, except for sparc64 which seems to need the flag -64 
                       |
   to be passed onto gcc.

  CT_LIBC_GLIBC_EXTRA_CFLAGS: 

   Extra target CFLAGS to use when building.

I've added the following to the latter option only :
-mfpu=maverick -mfloat-abi=softfp

since -mfpu=maverick is already in CFLAGS, it is probably  a dupe there 
as well.

Does that look like the correct place to put this?

Best regards.

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

Re: -mfloat-abi=softfp

[Martin Guy]

On 4/19/10, ng@piments.com <ng@piments.com> wrote:
> On 04/18/10 20:58, Martin Guy wrote:
> > On 4/18/10, ng@piments.com<ng@piments.com>  wrote:
> > >  I am experimenting with building a toolchain with maverick enabled
> based on
> > > patching gcc according to Martin Guy's patch set.
> > > http://martinwguy.co.uk/martin/crunch/
> > >
> > >  He suggests using -mfpu=maverick -mfloat-abi=softfp
> > probably be called LIBCFLAGS or something like that;
>
>   CT_LIBC_GLIBC_EXTRA_CFLAGS:
>   Extra target CFLAGS to use when building.
>
>  I've added the following to the latter option only :
>  -mfpu=maverick -mfloat-abi=softfp
>
>  Does that look like the correct place to put this?

That sounds like the one. There must also be -mcpu=ep9312, otherwise
the assembler fails to recognize the maverick asm instructions, even
though it is told -mfpu=maverick.

I tried building native glibc to get faster sin/cos etc but found that
it went into an infinite loop on certain values of sin(). However,
that was with an unmodified glibc source.
There are patches to put Maverick hacks into glibc, to do with
endianness, rounding modes, the FPU control word and more.

One is large: martinwguy.co.uk/crunch/glibc-crunch.patch
Another is very small and looks half-finished but may be worth investigating
martinwguy.co.uk/crunch/glibc-crunch2.patch

If you have any joy with these let me know.

Good luck!

   M

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

Re: -mfloat-abi=softfp

[Martin Guy]

On 4/19/10, Martin Guy <martinwguy@gmail.com> wrote:

>  One is large: martinwguy.co.uk/crunch/glibc-crunch.patch
>  Another is very small and looks half-finished but may be worth investigating
>  martinwguy.co.uk/crunch/glibc-crunch2.patch

I guess it would help if I got the URLs right

martinwguy.co.uk/martin/crunch/glibc-crunch.patch
martinwguy.co.uk/martin/crunch/glibc-crunch2.patch

der

    M

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

Re: -mfloat-abi=softfp

[ng]

On 04/19/10 11:53, Martin Guy wrote:
> On 4/19/10, Martin Guy<martinwguy@gmail.com>  wrote:
>
>>   One is large: martinwguy.co.uk/crunch/glibc-crunch.patch
>>   Another is very small and looks half-finished but may be worth investigating
>>   martinwguy.co.uk/crunch/glibc-crunch2.patch
>
> I guess it would help if I got the URLs right
>
> martinwguy.co.uk/martin/crunch/glibc-crunch.patch
> martinwguy.co.uk/martin/crunch/glibc-crunch2.patch
>
> der
>
>      M
>
Thanks, I've been trying what appears to be the same code from your link:
http://www.freelists.org/post/linux-cirrus/Yet-another-MaverickCrunch-hardware-bug,14

I split it into the binutils part and the glibc part to fit it into the 
ct-ng patch hierarchy.

Just guessing but could the loop be due to using fast-math? Inf and NaN 
are not always optional extras.

thanks for your help. I'll post back if I get some results running with 
the fpu.

regards.



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

Re: -mfloat-abi=softfp

[Martin Guy]

On 4/19/10, ng@piments.com <ng@piments.com> wrote:
>  Just guessing but could the loop be due to using fast-math? Inf and NaN are
> not always optional extras.

I wasn't using fast-math, and I think I also tried deleting the object
files for libm and rebuilding them using -mieee -fno-signed-zeros in
case it was a limit-of-precision thing.
Same result (unless it's a signed-zeros thing!!!)

Since I'm building natively, albeit on a different big fast ARM, it
takes about a day to perform each build and test - in the end I just
lost interest. Cross-compiling may allow you to explore more
possibilities

Good luck!

    M

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

Re: -mfloat-abi=softfp

[Martin Guy]

On 4/19/10, ng@piments.com <ng@piments.com> wrote:
> > On 4/19/10, Martin Guy<martinwguy@gmail.com>  wrote:
> >
> >
> > >  One is large:
> martinwguy.co.uk/crunch/glibc-crunch.patch
> > >  Another is very small and looks half-finished but may be worth
> investigating
> > >  martinwguy.co.uk/crunch/glibc-crunch2.patch
> > >
> >
> > I guess it would help if I got the URLs right
> >
> > martinwguy.co.uk/martin/crunch/glibc-crunch.patch
> > martinwguy.co.uk/martin/crunch/glibc-crunch2.patch

>  Thanks, I've been trying what appears to be the same code from your link:
> http://www.freelists.org/post/linux-cirrus/Yet-another-MaverickCrunch-hardware-bug,14

Yes, that looks like the same thing. THanks

    M

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

Re: -mfloat-abi=softfp

[ng]

On 04/19/10 11:51, Martin Guy wrote:
> On 4/19/10, ng@piments.com<ng@piments.com>  wrote:
>> On 04/18/10 20:58, Martin Guy wrote:
>>> On 4/18/10, ng@piments.com<ng@piments.com>   wrote:
>>>>   I am experimenting with building a toolchain with maverick enabled
>> based on
>>>> patching gcc according to Martin Guy's patch set.
>>>> http://martinwguy.co.uk/martin/crunch/
>>>>
>>>>   He suggests using -mfpu=maverick -mfloat-abi=softfp
>>> probably be called LIBCFLAGS or something like that;
>>
>>    CT_LIBC_GLIBC_EXTRA_CFLAGS:
>>    Extra target CFLAGS to use when building.
>>
>>   I've added the following to the latter option only :
>>   -mfpu=maverick -mfloat-abi=softfp
>>
>>   Does that look like the correct place to put this?
>
> That sounds like the one. There must also be -mcpu=ep9312, otherwise
> the assembler fails to recognize the maverick asm instructions, even
> though it is told -mfpu=maverick.
>
> I tried building native glibc to get faster sin/cos etc but found that
> it went into an infinite loop on certain values of sin(). However,
> that was with an unmodified glibc source.
> There are patches to put Maverick hacks into glibc, to do with
> endianness, rounding modes, the FPU control word and more.
>
> One is large: martinwguy.co.uk/crunch/glibc-crunch.patch
> Another is very small and looks half-finished but may be worth investigating
> martinwguy.co.uk/crunch/glibc-crunch2.patch
>
> If you have any joy with these let me know.
>
> Good luck!
>
>     M
>
Thanks Martin.

I'm having another stab at this . I've applied the two patches you 
suggest on your site.

I have built a 2.6.32.3 , non-crunch config that will create a toolchain 
capable of building a kernel .

So now  I've put
  LIBC_GLIBC_EXTRA_CFLAGS= -mfpu=maverick -mfloat-abi=softfp  -mcpu=ep9312

and selected hardware FP instructions.


It's throwing ICE in glibc.:


ux-gnueabi/build/gcc-core-shared/lib/gcc/arm-maverick-linux-gnueabi/4.3.4/include 
-isystem 
/back/ts/ct-ng/targets/arm-maverick-linux-gnueabi/build/gcc-core-shared/lib/gcc/arm-maverick-linux-gnueabi/4.3.4/include-fixed 
-isystem 
/back/ts/ct-ng/x-tools/arm-maverick-linux-gnueabi/arm-maverick-linux-gnueabi//sys-root/usr/include 
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC -DSHARED 
   -DNOT_IN_libc -o 
/back/ts/ct-ng/targets/arm-maverick-linux-gnueabi/build/build-libc/iconvdata/ibm420.os 
-MD -MP -MF 
/back/ts/ct-ng/targets/arm-maverick-linux-gnueabi/build/build-libc/iconvdata/ibm420.os.dt 
-MT 
/back/ts/ct-ng/targets/arm-maverick-linux-gnueabi/build/build-libc/iconvdata/ibm420.os
[ALL  ]    ibm420.c:1: warning: switch -mcpu=ep9312 conflicts with 
-march= switch
[ALL  ]    ../iconv/skeleton.c: In function 'gconv':
[ERROR]    ../iconv/skeleton.c:801: internal compiler error: 
Segmentation fault
[ALL  ]    Please submit a full bug report,
[ALL  ]    with preprocessed source if appropriate.



I ran ct-ng libc and it failed at the same point so that seems to rule 
out a hardware glitch.


I'm still uncertain about the -march warnings though Yann says to 
"forget" it.

  warning: switch -mcpu=ep9312 conflicts with -march= switch

I have left -mcpu -mtune empty in menuconfig giving just -march=armv4t

I was under the impression that maverick crunch issues were now resolved 
(at least within the bounds of the c++ caveats). Where am I going wrong?


best regards.


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

Re: -mfloat-abi=softfp

[Martin Guy]

On 4/27/10, ng@piments.com <ng@piments.com> wrote:
>  So now  I've put
>   LIBC_GLIBC_EXTRA_CFLAGS= -mfpu=maverick -mfloat-abi=softfp  -mcpu=ep9312
>
>  It's throwing ICE in glibc.:
>
>  [ALL  ]    ibm420.c:1: warning: switch -mcpu=ep9312 conflicts with -march=
> switch
>  [ALL  ]    ../iconv/skeleton.c: In function 'gconv':
>  [ERROR]    ../iconv/skeleton.c:801: internal compiler error: Segmentation
> fault
>  [ALL  ]    Please submit a full bug report,
>  [ALL  ]    with preprocessed source if appropriate.

ICE is a bug in the GCC that you are using to build the cross-compiler
- the "core compiler" - in this case, the output of your stage1
compilation. "Segmentation fault" is pretty severe :(
To investigate further where it is segfaulting you can run the one
specific command under gdb. I the core compiler is built using the
system glibc, so it shouldn't be a bug in the glibc patches. For what
it's worth, I've used the native gcc-4.3-crunch to build glibc again.
natively).

Another strategy you could use is to build gcc-4.2, which runs faster,
uses less memory to compile things and produces smaller and faster
code than gcc-4.3 (yes, really!)

>   warning: switch -mcpu=ep9312 conflicts with -march= switch
>  I have left -mcpu -mtune empty in menuconfig giving just -march=armv4t

-march=ep9312 should be what you need, but I doubt that will fix the ICE.

    M

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

Re: -mfloat-abi=softfp

[ng]

On 04/27/10 13:07, Martin Guy wrote:
> On 4/27/10, ng@piments.com<ng@piments.com>  wrote:
>>   So now  I've put
>>    LIBC_GLIBC_EXTRA_CFLAGS= -mfpu=maverick -mfloat-abi=softfp  -mcpu=ep9312
>>
>>   It's throwing ICE in glibc.:
>>
>>   [ALL  ]    ibm420.c:1: warning: switch -mcpu=ep9312 conflicts with -march=
>> switch
>>   [ALL  ]    ../iconv/skeleton.c: In function 'gconv':
>>   [ERROR]    ../iconv/skeleton.c:801: internal compiler error: Segmentation
>> fault
>>   [ALL  ]    Please submit a full bug report,
>>   [ALL  ]    with preprocessed source if appropriate.
>
> ICE is a bug in the GCC that you are using to build the cross-compiler
> - the "core compiler" - in this case, the output of your stage1
> compilation. "Segmentation fault" is pretty severe :(
> To investigate further where it is segfaulting you can run the one
> specific command under gdb. I the core compiler is built using the
> system glibc, so it shouldn't be a bug in the glibc patches. For what
> it's worth, I've used the native gcc-4.3-crunch to build glibc again.
> natively).
>
> Another strategy you could use is to build gcc-4.2, which runs faster,
> uses less memory to compile things and produces smaller and faster
> code than gcc-4.3 (yes, really!)
>
>>    warning: switch -mcpu=ep9312 conflicts with -march= switch
>>   I have left -mcpu -mtune empty in menuconfig giving just -march=armv4t
>
> -march=ep9312 should be what you need, but I doubt that will fix the ICE.
>
>      M
>
Thanks Martin,

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

man gcc (4.3.4) says:

`-march=NAME'
      This specifies the name of the target ARM architecture.  GCC uses
      this name to determine what kind of instructions it can emit when
      generating assembly code.  This option can be used in conjunction
      with or instead of the `-mcpu=' option.  Permissible names are:
      `armv2', `armv2a', `armv3', `armv3m', `armv4', `armv4t', `armv5',
      `armv5t', `armv5te', `armv6', `armv6j', `armv6t2', `armv6z',
      `armv6zk', `armv7', `armv7-a', `armv7-r', `armv7-m', `iwmmxt',
      `ep9312'.

:?
I did not try this config with 4.3.4.

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?

Now trying your suggestion of 4.2.4

thx

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

Re: -mfloat-abi=softfp

[ng]

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

Re: -mfloat-abi=softfp

[ng]

On 04/27/10 13:07, Martin Guy wrote:
> On 4/27/10, ng@piments.com<ng@piments.com>  wrote:
>>   So now  I've put
>>    LIBC_GLIBC_EXTRA_CFLAGS= -mfpu=maverick -mfloat-abi=softfp  -mcpu=ep9312
>>
>>   It's throwing ICE in glibc.:
>>
>>   [ALL  ]    ibm420.c:1: warning: switch -mcpu=ep9312 conflicts with -march=
>> switch
>>   [ALL  ]    ../iconv/skeleton.c: In function 'gconv':
>>   [ERROR]    ../iconv/skeleton.c:801: internal compiler error: Segmentation
>> fault
>>   [ALL  ]    Please submit a full bug report,
>>   [ALL  ]    with preprocessed source if appropriate.
>
> ICE is a bug in the GCC that you are using to build the cross-compiler
> - the "core compiler" - in this case, the output of your stage1
> compilation. "Segmentation fault" is pretty severe :(
> To investigate further where it is segfaulting you can run the one
> specific command under gdb. I the core compiler is built using the
> system glibc, so it shouldn't be a bug in the glibc patches. For what
> it's worth, I've used the native gcc-4.3-crunch to build glibc again.
> natively).
>
> Another strategy you could use is to build gcc-4.2, which runs faster,
> uses less memory to compile things and produces smaller and faster
> code than gcc-4.3 (yes, really!)
>
>>    warning: switch -mcpu=ep9312 conflicts with -march= switch
>>   I have left -mcpu -mtune empty in menuconfig giving just -march=armv4t
>
> -march=ep9312 should be what you need, but I doubt that will fix the ICE.
>
>      M
>

just got this from system log when running 4.2.4 based build.


.
Apr 27 15:06:23 linbox kernel: wlan1: deauthenticating by local choice 
(reason=3)
Apr 27 15:06:23 linbox dhcpcd[8426]: wlan1: carrier lost
Apr 27 15:06:23 linbox dhcpcd[8426]: wlan1: carrier_status: No such device
Apr 27 15:07:17 linbox smartd[2923]: Device: /dev/hda, SMART Usage 
Attribute: 194 Temperature_Celsius changed from 42 to 43
Apr 27 15:11:28 linbox kernel: BUG: unable to handle kernel NULL pointer 
dereference at 00000006
Apr 27 15:11:28 linbox kernel: IP: [<00000006>] 0x6
Apr 27 15:11:28 linbox kernel: *pde = 00000000
Apr 27 15:11:28 linbox kernel: Oops: 0000 [#1]
Apr 27 15:11:28 linbox kernel: last sysfs file: 
/sys/devices/pci0000:00/0000:00:01.1/i2c-adapter/i2c-1/1-002d/cpu0_vid
Apr 27 15:11:28 linbox kernel: Modules linked in: aes_generic arc4 ecb 
rt73usb rt2x00usb rt2x00lib mac80211 cfg80211 bridge stp llc 
snd_seq_midi snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss 
snd_mixer_oss snd_rtctimer asb100 hwmon_vid hwmon fuse analog joydev 
usblp nvidia(P) snd_ens1371 gameport snd_rawmidi snd_seq_device 
snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc 
ohci_hcd ehci_hcd forcedeth e100 3c59x i2c_nforce2 i2c_core nvidia_agp 
evdev agpgart thermal processor
Apr 27 15:11:28 linbox kernel:
Apr 27 15:11:28 linbox kernel: Pid: 17757, comm: make Tainted: P 
    (2.6.29-hh2 #9) A7N8X
Apr 27 15:11:28 linbox kernel: EIP: 0060:[<00000006>] EFLAGS: 00010083 
CPU: 0
Apr 27 15:11:28 linbox kernel: EIP is at 0x6
Apr 27 15:11:28 linbox kernel: EAX: ddf19fbc EBX: 40190ff4 ECX: 0000007b 
EDX: 400bb096
Apr 27 15:11:28 linbox kernel: ESI: 08208fe0 EDI: 00000006 EBP: bfb7ed08 
ESP: ddf19fb8
Apr 27 15:11:28 linbox kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Apr 27 15:11:28 linbox kernel: Process make (pid: 17757, ti=ddf18000 
task=f2423660 task.ti=ddf18000)
Apr 27 15:11:28 linbox kernel: Stack:
Apr 27 15:11:28 linbox kernel: c045df22 40190ff4 08209030 0001cfd1 
08208fe0 08208fe0 bfb7ed08 00000018
Apr 27 15:11:28 linbox kernel: 0000007b 0000007b 00000000 ffffffff 
00000073 00010206 bfb7ec58 0000007b
Apr 27 15:11:28 linbox kernel: 00000000 00000000
Apr 27 15:11:28 linbox kernel: Call Trace:
Apr 27 15:11:28 linbox kernel: [<c045df22>] error_code+0x6a/0x70
Apr 27 15:11:28 linbox kernel: Code:  Bad EIP value.
Apr 27 15:11:28 linbox kernel: EIP: [<00000006>] 0x6 SS:ESP 0068:ddf19fb8
Apr 27 15:11:28 linbox kernel: ---[ end trace 3b01e823d1d7f2a3 ]---



The ct-ng log looks like this:


[ALL  ]    echo '' > 
/back/ts/ct-ng/targets/arm-maverick-linux-gnueabi/build/build-libc/socket/stamp.oST
[ALL  ]    mv -f 
/back/ts/ct-ng/targets/arm-maverick-linux-gnueabi/build/build-libc/socket/stamp.oST 
/back/ts/ct-ng/targets/arm-maverick-linux-gnueabi/build/build-libc/socket/stamp.oS
[ALL  ]    make[3]: Leaving directory 
`/back/ts/ct-ng/targets/src/glibc-2.9/socket'
[ALL  ]    /usr/bin/make -j1 subdir=sysvipc -C sysvipc ..=../ subdir_lib
[ERROR]    make[2]: *** [sysvipc/subdir_lib] Segmentation fault
[ALL  ]    make[2]: Leaving directory `/back/ts/ct-ng/targets/src/glibc-2.9'
[ERROR]    make[1]: *** [all] Error 2


Can you make any sense of that?

thx

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

Re: -mfloat-abi=softfp

[Martin Guy]

On 4/27/10, ng@piments.com <ng@piments.com> wrote:
>  Apr 27 15:11:28 linbox kernel: BUG: unable to handle kernel NULL pointer
> dereference at 00000006

It looks like your computer has hardware problems. Try turning it off
and on again, run your first build again and see if you get the same
failure at the same place.
If you don't. you either have flaky RAM, an overheated CPU, spikes on
the electricity supply, an inadequate power supply or you are a magnet
for cosmic rays.

    M

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

Re: -mfloat-abi=softfp

[ng]

On 04/28/10 10:52, Martin Guy wrote:
>>   The major worry seems to be the NAND flash.
>>
>>   Creating 3 MTD partitions on "ts7250-nand":
>>   Since there is specific support for the TS7250 boards.and I had no problems
>> on 2.6.29 , I'm a bit confused.
>>
>>   Both the "Bad eraseblock 0" error and the  "TS-BOOTROM" doesn't end on an
>> erase block " issue seems be fairly common in the embedded world, I have not
>> found any concrete information on what the cause is.
>>
>>   Can you suggest where I should be looking?
>
> I'm glad there was nothing wrong with crosstool-ng. Lesson: don't
> overclock unless you are only running games. However this no longer
> has anything to do with cross-compilation using gcc, so the answer is
> probably "the ts7000 yahoo group or your supplier".
>
> Alternatively you can hire me to solve your problems.
>
>     M
>
Hi again.

I have been doing well with the toolchain but it's now tripping up on 
gnuplot.

./configure --host=arm-maverick-linux-gnueabi --without-x--without-pdf 
--without-cairo --disable-wxwidgets --without-x CFLAGS=" -mcpu=ep9312 
-mfpu=maverick -mfloat-abi=softfp -O2 -fomit-frame-pointer -pipe" 
CXXFLAGS=" -mcpu=ep9312 -mfpu=maverick -mfloat-abi=softfp -O2 
-fomit-frame-pointer -pipe"

make

make[3]: Entering directory `/back/ts/ct-wkg/gnuplot/src'
arm-maverick-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I..  -I../term 
-I../term -DBINDIR=\"/usr/local/bin\" 
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.3\" 
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.3/PostScript\" 
-DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.3/js\" 
-DCONTACT=\"gnuplot-bugs@lists.sourceforge.net\" 
-DHELPFILE=\"/usr/local/share/gnuplot/4.3/gnuplot.gih\" 
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -mcpu=ep9312 
-mfpu=maverick -mfloat-abi=softfp -O2 -fomit-frame-pointer -pipe -MT 
axis.o -MD -MP -MF .deps/axis.Tpo -c -o axis.o axis.c
axis.c: In function 'gen_tics':
axis.c:1163: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [axis.o] Error 1
make[3]: Leaving directory `/back/ts/ct-wkg/gnuplot/src'
make[2]: *** [all-recursive] Error 1


This is a genuine ICE. 100% repeatable .

I had also been seeing the "-march= switch" jive again until I removed 
-march=armv4t from the flags.

The ICE is the same with or with that detail.

If I remove teh " -mfpu=maverick -mfloat-abi=softfp" part it compiles.

Unfortunately gnuplot was the main reason I got into all this FPU work 
in the first place, though moving to eabi was a huge improvement already.

thx

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