[Buildroot] ARM EABI builds

[Buildroot] ARM EABI builds

[Ben Dooks]

Has anyone had success with building an EABI buildroot? I have tried
building ARM (arm920t,gcc 4.1.2) and the image produced hangs (it
seems vfprintf does not work)

I have succesfully built images with gcc 4.1.2 and a patch to make it
build gcc with OABI.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Tom]

Ben Dooks wrote:
> Has anyone had success with building an EABI buildroot? I have tried
> building ARM (arm920t,gcc 4.1.2) and the image produced hangs (it
> seems vfprintf does not work)
> 
> I have succesfully built images with gcc 4.1.2 and a patch to make it
> build gcc with OABI.
> 

Yes, I had success. (After an issue described in "[Buildroot] Arm / 
buildroot / kernel issue: init crashes?", maybe this is your problem too.)

[Buildroot] ARM EABI builds

[Ben Dooks]

On Tue, Jun 26, 2007 at 02:19:19PM -0700, Tom wrote:
> Ben Dooks wrote:
> >Has anyone had success with building an EABI buildroot? I have tried
> >building ARM (arm920t,gcc 4.1.2) and the image produced hangs (it
> >seems vfprintf does not work)
> >
> >I have succesfully built images with gcc 4.1.2 and a patch to make it
> >build gcc with OABI.
> >
> 
> Yes, I had success. (After an issue described in "[Buildroot] Arm / 
> buildroot / kernel issue: init crashes?", maybe this is your problem too.)

Next time, could you please post an URL, it doesn't seem to be trivially
findable with google.

I have tried EABI build with what should be an EABI only kernel, and this
still shows that /bin/sh is not running to a point where you can interact
with it.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Ben Dooks]

On Tue, Jun 26, 2007 at 11:25:00PM +0100, Ben Dooks wrote:
> On Tue, Jun 26, 2007 at 02:19:19PM -0700, Tom wrote:
> > Ben Dooks wrote:
> > >Has anyone had success with building an EABI buildroot? I have tried
> > >building ARM (arm920t,gcc 4.1.2) and the image produced hangs (it
> > >seems vfprintf does not work)
> > >
> > >I have succesfully built images with gcc 4.1.2 and a patch to make it
> > >build gcc with OABI.
> > >
> > 
> > Yes, I had success. (After an issue described in "[Buildroot] Arm / 
> > buildroot / kernel issue: init crashes?", maybe this is your problem too.)
> 
> Next time, could you please post an URL, it doesn't seem to be trivially
> findable with google.
> 
> I have tried EABI build with what should be an EABI only kernel, and this
> still shows that /bin/sh is not running to a point where you can interact
> with it.

I have finally tracked down the problem, and will be submitting a
fix as soon as I have reviewed the patch.

The basic problem is as so:

1) Buildroot asks for the processor type (ARM920,etc)
2) Buildroot does not pass this to gcc when building
3) GCC makes a guess about architecture based on internal configuration
4) GCC EABI defaults to ARMv5
5) ARMv5 produces instructions that cannot execute on ARMv4
6) applications fail to work due to invalid instructions in libgcc

The first part of the solution is to pass --with-cpu=<cpu> to the
gcc configuration, thus forcing the use of a particular cpu and
architecture.

The next thing is, do we then need to produce our compiler and
libraries in toolchain_arm_<cpu>_<fp> and build_arm_<cpu>_<fp> ?

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Konstantin Kletschke]

Am 2007-06-27 09:19 +0100 schrieb Ben Dooks:

> I have finally tracked down the problem, and will be submitting a
> fix as soon as I have reviewed the patch.

*argh* 

I followed your thread and I am so sorry that I forgot that I for myself
apply a patch regarding this issue. It floated around a while ago and
it is called unbreak-armv4t.patch:

ff -urN gcc-4.1.1/gcc/config/arm/linux-eabi.h gcc-4.1.1-arm9tdmi/gcc/config/arm/linux-eabi.h
--- gcc-4.1.1/gcc/config/arm/linux-eabi.h       2006-10-22 11:11:49.000000000 -0700
+++ gcc-4.1.1-arm9tdmi/gcc/config/arm/linux-eabi.h      2006-10-24 21:34:01.000000000 -0700
@@ -45,7 +45,7 @@
    The ARM10TDMI core is the default for armv5t, so set
    SUBTARGET_CPU_DEFAULT to achieve this.  */
 #undef SUBTARGET_CPU_DEFAULT
-#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi
+#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9tdmi

 #undef SUBTARGET_EXTRA_LINK_SPEC
 #define SUBTARGET_EXTRA_LINK_SPEC " -m armelf_linux_eabi"


> The next thing is, do we then need to produce our compiler and
> libraries in toolchain_arm_<cpu>_<fp> and build_arm_<cpu>_<fp> ?

Well... why not? The toolchain_arm_<cpu>_<fp> directory is some sort of
PIC in the filesystem and can moved around and used for crosscompiling
other stuff standing alone.

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[Buildroot] ARM EABI builds

[Ben Dooks]

On Wed, Jun 27, 2007 at 11:03:29AM +0200, Konstantin Kletschke wrote:
> Am 2007-06-27 09:19 +0100 schrieb Ben Dooks:
> 
> > I have finally tracked down the problem, and will be submitting a
> > fix as soon as I have reviewed the patch.
> 
> *argh* 
> 
> I followed your thread and I am so sorry that I forgot that I for myself
> apply a patch regarding this issue. It floated around a while ago and
> it is called unbreak-armv4t.patch:

Whilst this is also a fix, I think that passing --with-cpu= to the
compiler at generation time is a better option. This will allow OABI
builds for any pre-armv4 sytems, and ensure that xscale/v5/v6/etc will
also produce optimal output as they will be configured with the correct
cpu architecture.
 
> ff -urN gcc-4.1.1/gcc/config/arm/linux-eabi.h gcc-4.1.1-arm9tdmi/gcc/config/arm/linux-eabi.h
> --- gcc-4.1.1/gcc/config/arm/linux-eabi.h       2006-10-22 11:11:49.000000000 -0700
> +++ gcc-4.1.1-arm9tdmi/gcc/config/arm/linux-eabi.h      2006-10-24 21:34:01.000000000 -0700
> @@ -45,7 +45,7 @@
>     The ARM10TDMI core is the default for armv5t, so set
>     SUBTARGET_CPU_DEFAULT to achieve this.  */
>  #undef SUBTARGET_CPU_DEFAULT
> -#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi
> +#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9tdmi
> 
>  #undef SUBTARGET_EXTRA_LINK_SPEC
>  #define SUBTARGET_EXTRA_LINK_SPEC " -m armelf_linux_eabi"
> 
> 
> > The next thing is, do we then need to produce our compiler and
> > libraries in toolchain_arm_<cpu>_<fp> and build_arm_<cpu>_<fp> ?
> 
> Well... why not? The toolchain_arm_<cpu>_<fp> directory is some sort of
> PIC in the filesystem and can moved around and used for crosscompiling
> other stuff standing alone.

That was more a request for comments, it can sometimes be difficult
to guage exactly how people view these things until you've asked.

It would also need EABI/OABI in there. I tried switching an already
configured buildroot from EABI to OABI, and found that it did not
build correctly (but that is for another post).

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Tom]

Ben Dooks wrote:
> On Tue, Jun 26, 2007 at 11:25:00PM +0100, Ben Dooks wrote:
>> On Tue, Jun 26, 2007 at 02:19:19PM -0700, Tom wrote:
>>> Ben Dooks wrote:
>>>> Has anyone had success with building an EABI buildroot? I have tried
>>>> building ARM (arm920t,gcc 4.1.2) and the image produced hangs (it
>>>> seems vfprintf does not work)
>>>>
>>>> I have succesfully built images with gcc 4.1.2 and a patch to make it
>>>> build gcc with OABI.
>>>>
>>> Yes, I had success. (After an issue described in "[Buildroot] Arm / 
>>> buildroot / kernel issue: init crashes?", maybe this is your problem too.)
>> Next time, could you please post an URL, it doesn't seem to be trivially
>> findable with google.
>>
>> I have tried EABI build with what should be an EABI only kernel, and this
>> still shows that /bin/sh is not running to a point where you can interact
>> with it.
> 
> I have finally tracked down the problem, and will be submitting a
> fix as soon as I have reviewed the patch.
> 
> The basic problem is as so:
> 
> 1) Buildroot asks for the processor type (ARM920,etc)
> 2) Buildroot does not pass this to gcc when building
> 3) GCC makes a guess about architecture based on internal configuration
> 4) GCC EABI defaults to ARMv5
> 5) ARMv5 produces instructions that cannot execute on ARMv4
> 6) applications fail to work due to invalid instructions in libgcc
> 
> The first part of the solution is to pass --with-cpu=<cpu> to the
> gcc configuration, thus forcing the use of a particular cpu and
> architecture.
> 
> The next thing is, do we then need to produce our compiler and
> libraries in toolchain_arm_<cpu>_<fp> and build_arm_<cpu>_<fp> ?
> 
We need to keep in mind that the same gcc toolchain can support several 
subarchitectures, thus this naming would be somewhat misleading (for 
example, in our cases it did produce both ARMv4 (in the kernel) and 
ARMv5 (in user libs)).

To me it would be great if the gcc toolchain always printed out whatever 
the default SUBTARGET / CPU is as part of its specs. (It does this only 
if one is passed with the --with-cpu option, so if it's not passed, you 
can't easily find the default.) This would have helped me immensely to 
find the --with-cpu workaround, but I am afraid this is not really a 
buildroot issue.

[Buildroot] ARM EABI builds

[Ben Dooks]

On Wed, Jun 27, 2007 at 10:44:23AM -0700, Tom wrote:
> Ben Dooks wrote:
> >On Tue, Jun 26, 2007 at 11:25:00PM +0100, Ben Dooks wrote:
> >>On Tue, Jun 26, 2007 at 02:19:19PM -0700, Tom wrote:
> >>>Ben Dooks wrote:
> >>>>Has anyone had success with building an EABI buildroot? I have tried
> >>>>building ARM (arm920t,gcc 4.1.2) and the image produced hangs (it
> >>>>seems vfprintf does not work)
> >>>>
> >>>>I have succesfully built images with gcc 4.1.2 and a patch to make it
> >>>>build gcc with OABI.
> >>>>
> >>>Yes, I had success. (After an issue described in "[Buildroot] Arm / 
> >>>buildroot / kernel issue: init crashes?", maybe this is your problem 
> >>>too.)
> >>Next time, could you please post an URL, it doesn't seem to be trivially
> >>findable with google.
> >>
> >>I have tried EABI build with what should be an EABI only kernel, and this
> >>still shows that /bin/sh is not running to a point where you can interact
> >>with it.
> >
> >I have finally tracked down the problem, and will be submitting a
> >fix as soon as I have reviewed the patch.
> >
> >The basic problem is as so:
> >
> >1) Buildroot asks for the processor type (ARM920,etc)
> >2) Buildroot does not pass this to gcc when building
> >3) GCC makes a guess about architecture based on internal configuration
> >4) GCC EABI defaults to ARMv5
> >5) ARMv5 produces instructions that cannot execute on ARMv4
> >6) applications fail to work due to invalid instructions in libgcc
> >
> >The first part of the solution is to pass --with-cpu=<cpu> to the
> >gcc configuration, thus forcing the use of a particular cpu and
> >architecture.
> >
> >The next thing is, do we then need to produce our compiler and
> >libraries in toolchain_arm_<cpu>_<fp> and build_arm_<cpu>_<fp> ?
> >
> We need to keep in mind that the same gcc toolchain can support several 
> subarchitectures, thus this naming would be somewhat misleading (for 
> example, in our cases it did produce both ARMv4 (in the kernel) and 
> ARMv5 (in user libs)).

Yes, the naming would indicate the default cpu the compiler is configured
for. The gcc docs[1] indicate the --with-cpu= option only sets the
default cpu to compile for. Unfortunately this affects how it produces
libgcc.

I don't see why you would end up producing ARMv4 kernel when producing
an ARMv5 user space. Either you are producing a kernel to run on the 
same arch as your userspace (the kernel will correctly assign -mcpu=<x>)
when it is building.
 
> To me it would be great if the gcc toolchain always printed out whatever 
> the default SUBTARGET / CPU is as part of its specs. (It does this only 
> if one is passed with the --with-cpu option, so if it's not passed, you 
> can't easily find the default.) This would have helped me immensely to 
> find the --with-cpu workaround, but I am afraid this is not really a 
> buildroot issue.

It is part of a problem with gcc where libgcc is being built for some
arbitrary default, instead of one suitable for each architecture that
can be selected at run-time.

The problem with buildroot is that it gives you a choice of ARM cpus.
If you select ARM920T, then you have an expectation of being able
to run the binaries produced on an ARM920T, which currently if EABI
is also selected is impossible.

I did think about adding -mcpu=<cpu> to the build CFLAGS, but that
is not going to help with the problem that libgcc is not going to
be compiled correctly.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Tom]

Ben Dooks wrote:
>> We need to keep in mind that the same gcc toolchain can support several 
>> subarchitectures, thus this naming would be somewhat misleading (for 
>> example, in our cases it did produce both ARMv4 (in the kernel) and 
>> ARMv5 (in user libs)).
> 
> Yes, the naming would indicate the default cpu the compiler is configured
> for. The gcc docs[1] indicate the --with-cpu= option only sets the
> default cpu to compile for. Unfortunately this affects how it produces
> libgcc.
> 
> I don't see why you would end up producing ARMv4 kernel when producing
> an ARMv5 user space. Either you are producing a kernel to run on the 
> same arch as your userspace (the kernel will correctly assign -mcpu=<x>)
> when it is building.
>  
Why? Because of the bug: Configured all builds with ARM920T:
Buildroot creates "incorrect" toolchain, "incorrect" toolchain fails to 
build uclibc in ARMv4 only  but uses ARMv5. However, it did build a 
kernel in ARMv4 fine.


>> To me it would be great if the gcc toolchain always printed out whatever 
>> the default SUBTARGET / CPU is as part of its specs. (It does this only 
>> if one is passed with the --with-cpu option, so if it's not passed, you 
>> can't easily find the default.) This would have helped me immensely to 
>> find the --with-cpu workaround, but I am afraid this is not really a 
>> buildroot issue.
> 
> It is part of a problem with gcc where libgcc is being built for some
> arbitrary default, instead of one suitable for each architecture that
> can be selected at run-time.
> 
> The problem with buildroot is that it gives you a choice of ARM cpus.
> If you select ARM920T, then you have an expectation of being able
> to run the binaries produced on an ARM920T, which currently if EABI
> is also selected is impossible.

Yes, I agree. I like your solution in 
http://busybox.net/bugs/view.php?id=1406 .

> 
> I did think about adding -mcpu=<cpu> to the build CFLAGS, but that
> is not going to help with the problem that libgcc is not going to
> be compiled correctly.
> 
Why not? The kernel image, built with the same "incorrect" toolchain, 
must have used only ARMv4 instructions. If it hadn't, I would have never 
gotten far enough to even execute vprintf, libc. I would suspect that 
the kernel does a better job of setting -mcpu, -mtune. Thus these 
options should work for libc too. What makes you think that it wouldn't 
work for libc, have you tried? (PS: Even if it did, bug #1406 is 
probably the better fix, in particular as buildroot users might use its 
toolchain to build their own code w/o always setting these options)

[Buildroot] ARM EABI builds

[Ben Dooks]

On Thu, Jun 28, 2007 at 12:13:18PM -0700, Tom wrote:
> Ben Dooks wrote:
> >>We need to keep in mind that the same gcc toolchain can support several 
> >>subarchitectures, thus this naming would be somewhat misleading (for 
> >>example, in our cases it did produce both ARMv4 (in the kernel) and 
> >>ARMv5 (in user libs)).
> >
> >Yes, the naming would indicate the default cpu the compiler is configured
> >for. The gcc docs[1] indicate the --with-cpu= option only sets the
> >default cpu to compile for. Unfortunately this affects how it produces
> >libgcc.
> >
> >I don't see why you would end up producing ARMv4 kernel when producing
> >an ARMv5 user space. Either you are producing a kernel to run on the 
> >same arch as your userspace (the kernel will correctly assign -mcpu=<x>)
> >when it is building.
> > 
> Why? Because of the bug: Configured all builds with ARM920T:
> Buildroot creates "incorrect" toolchain, "incorrect" toolchain fails to 
> build uclibc in ARMv4 only  but uses ARMv5. However, it did build a 
> kernel in ARMv4 fine.
> 
> 
> >>To me it would be great if the gcc toolchain always printed out whatever 
> >>the default SUBTARGET / CPU is as part of its specs. (It does this only 
> >>if one is passed with the --with-cpu option, so if it's not passed, you 
> >>can't easily find the default.) This would have helped me immensely to 
> >>find the --with-cpu workaround, but I am afraid this is not really a 
> >>buildroot issue.
> >
> >It is part of a problem with gcc where libgcc is being built for some
> >arbitrary default, instead of one suitable for each architecture that
> >can be selected at run-time.
> >
> >The problem with buildroot is that it gives you a choice of ARM cpus.
> >If you select ARM920T, then you have an expectation of being able
> >to run the binaries produced on an ARM920T, which currently if EABI
> >is also selected is impossible.
> 
> Yes, I agree. I like your solution in 
> http://busybox.net/bugs/view.php?id=1406 .
> 
> >
> >I did think about adding -mcpu=<cpu> to the build CFLAGS, but that
> >is not going to help with the problem that libgcc is not going to
> >be compiled correctly.
> >
> Why not? The kernel image, built with the same "incorrect" toolchain, 
> must have used only ARMv4 instructions. If it hadn't, I would have never 

1) the kernel passed -march= and -mcpu= to the compiler
2) the kernel does not use libgcc.a to provide compiler support

this ensures the kernel will not build code which cannot be run on
the target system. if you look at arch/arm/Makefile you'll see an
number of compiler configurations based on arch and compiler version
being used. In fact, if another compiler came along, it is entirely
possible the kernel could be modified to use that instead.

passing -mcpu= to the application builds will ensure that the application
is built for the correct cpu, but unfortunately there is the possibility
that libgcc (built as part of the compiler build) will have been configured
with invalid instructions.

> gotten far enough to even execute vprintf, libc. I would suspect that 
> the kernel does a better job of setting -mcpu, -mtune. Thus these 
> options should work for libc too. What makes you think that it wouldn't 
> work for libc, have you tried? (PS: Even if it did, bug #1406 is 
> probably the better fix, in particular as buildroot users might use its 
> toolchain to build their own code w/o always setting these options)

the configuration for gcc's default build for userland must be for the
lowest common denominator that the build is going to run on, otherwise
libgcc will be produced with invalid instructions.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Ulf Samuelsson]

> 
> The problem with buildroot is that it gives you a choice of ARM cpus.
> If you select ARM920T, then you have an expectation of being able
> to run the binaries produced on an ARM920T, which currently if EABI
> is also selected is impossible.
> 

So should we not just make EABI depend on !ARM920T

Best Regards
Ulf Samuelsson

[Buildroot] ARM EABI builds

[Tom]

Ulf Samuelsson wrote:
>> The problem with buildroot is that it gives you a choice of ARM cpus.
>> If you select ARM920T, then you have an expectation of being able
>> to run the binaries produced on an ARM920T, which currently if EABI
>> is also selected is impossible.
>>
> 
> So should we not just make EABI depend on !ARM920T
> 

I would say no, because this combination works for buildroot. (However, 
if you _only_ select ARM920T and EABI and don't take care of the CPU 
options, it will fail.)

[Buildroot] ARM EABI builds

[Ben Dooks]

On Thu, Jun 28, 2007 at 04:57:32PM -0700, Tom wrote:
> Ulf Samuelsson wrote:
> >>The problem with buildroot is that it gives you a choice of ARM cpus.
> >>If you select ARM920T, then you have an expectation of being able
> >>to run the binaries produced on an ARM920T, which currently if EABI
> >>is also selected is impossible.
> >>
> >
> >So should we not just make EABI depend on !ARM920T
> >

1) EABI will work fine on ARM920T (and other ARMv4) targets 
2) Currently, until other patches, a number of the available gcc choices
   do not currently build a compiler, let alone make it to the application
   stage.
3) The proposed fix in 1406 attempts to ensure that down the road we don't
   fall into this trap again.
 
> I would say no, because this combination works for buildroot. (However, 
> if you _only_ select ARM920T and EABI and don't take care of the CPU 
> options, it will fail.)

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Stuart Wood]

Just a note on what Tom said about user land application. I've already 
found that I had to add -march=armv4t to properly build my application, Just
because gcc was not using the right load register code for the data 
size I wanted to read. It would use ldrw instead of ldrh. So, It would 
help avoid those errors.

Stuart

Tom wrote:
> 
> I did think about adding -mcpu=<cpu> to the build CFLAGS, but that is
> not going to help with the problem that libgcc is not going to be 
> compiled correctly.
> 
Why not? The kernel image, built with the same "incorrect" toolchain, 
must have used only ARMv4 instructions. If it hadn't, I would have never 
gotten far enough to even execute vprintf, libc. I would suspect that 
the kernel does a better job of setting -mcpu, -mtune. Thus these 
options should work for libc too. What makes you think that it wouldn't 
work for libc, have you tried? (PS: Even if it did, bug #1406 is 
probably the better fix, in particular as buildroot users might use its 
toolchain to build their own code w/o always setting these options)


_______________________________________________
buildroot mailing list
buildroot at uclibc.org http://busybox.net/mailman/listinfo/buildroot

[Buildroot] ARM EABI builds

[Bernhard Fischer]

On Thu, Jun 28, 2007 at 03:54:22PM -0400, Stuart Wood wrote:
>Just a note on what Tom said about user land application. I've already 

Just as a note on what everybody seems to say about configuring GCC:
It is very amusing that you guys seem to be excited about _not_ setting
a config option -- CONFIG_BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS -- which
is specifically exported to you, to spell out specific requirements put
upon gcc (other toolchain parts of course also provide said means for
hand-crafted  options, mind you).

>found that I had to add -march=armv4t to properly build my application, Just

doh!

>because gcc was not using the right load register code for the data 

well, if you don't tell it to do and _do not help in improving the
generic situation_ how should we guess what you are trying to achieve?

Get real. (yes, i'm in a bad mood and i'm fond of stupid whining about
'Doctor, it hurts when i..'

Q:
Dear X-mas whatever. I want this and that. Now. Immediately. No, i have
no idea how to implement 'this' 'now', but it has to be done. What? Nah,
no idea what 'this' nor 'that' nor 'now' is supposed to do, i'd have
provided a guidance otherwise.
A: alright. At your service.

>size I wanted to read. It would use ldrw instead of ldrh. So, It would 
>help avoid those errors.

Try searching the archives for CPU selection (from memory, so may not be
accurate) for further details.
>
>Stuart

See below.
>
>Tom wrote:
>> 
>> I did think about adding -mcpu=<cpu> to the build CFLAGS, but that is
>> not going to help with the problem that libgcc is not going to be 
>> compiled correctly.
>> 
>Why not? The kernel image, built with the same "incorrect" toolchain, 
>must have used only ARMv4 instructions. If it hadn't, I would have never 
>gotten far enough to even execute vprintf, libc. I would suspect that 
>the kernel does a better job of setting -mcpu, -mtune. Thus these 
>options should work for libc too. What makes you think that it wouldn't 
>work for libc, have you tried? (PS: Even if it did, bug #1406 is 
>probably the better fix, in particular as buildroot users might use its 

bug #1406 is completely crap. Let me cite:
<quote>
 Reporter  	 bjdooks
 Summary  	 0001403: printf and anything using vfprintf() hangs
 system
 Description 	Any function using vfprintf, such as printf and snprintf
 cause the system to stop. A test program shows that stdout is
 functional, as fwrite() to stdout will display messages on the console
 Additional Information 	uclibc 0.9.29
 gcc 4.1.2 (arm-linux-uclibcgnueabi)
 binutils 2.17.50.0.16
 configure for ARM920T, EABI
---
(0002514)
bjdooks
06-25-07 17:26

	The bug is still present in the development snapshot 
---
(0002517)
bjdooks
06-26-07 05:03

	Building gcc 4.1.2 for OABI (patches will be sent in seperate
	report) does not work either.
</quote>
>toolchain to build their own code w/o always setting these options)

- No actual error shown.
- no code/arch/toolchain hints to reproduce.
This is one of the 'Doctor, it hurts'.. goto above;

[Buildroot] ARM EABI builds

[Tom]

Bernhard Fischer wrote:
> On Thu, Jun 28, 2007 at 03:54:22PM -0400, Stuart Wood wrote:
>> Just a note on what Tom said about user land application. I've already 
> 
> Just as a note on what everybody seems to say about configuring GCC:
> It is very amusing that you guys seem to be excited about _not_ setting
> a config option -- CONFIG_BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS -- which
> is specifically exported to you, to spell out specific requirements put
> upon gcc (other toolchain parts of course also provide said means for
> hand-crafted  options, mind you).

Speaking for myself, I am not excited about any particular option. Also 
I don't need a doctor for this anymore, as for my part it works. Now.

However, as the combination EABI and ARM9 seems to be popular, I thought 
it would be nice to save others some of this trouble that they are bound 
to run into (*), either by just mentioning the option or by setting it 
automatically in buildroot. If you are saying that 
CONFIG_BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS is better suited for the 
required target CPU option than BR2_EXTRA_GCC_CONFIG_OPTIONS, that could 
very well be.

(*) This is the error I got after kernel boot on ARM920T/EABI default 
config, w/o the required CPU option:
init (1): undefined instruction: pc=00008c60
This error with buildroot and busybox configurations have been mailed to 
this group, please let me know if you would like me to attach this to a bug.


> 
>> found that I had to add -march=armv4t to properly build my application, Just
> 
> doh!
> 
>> because gcc was not using the right load register code for the data 
> 
> well, if you don't tell it to do and _do not help in improving the
> generic situation_ how should we guess what you are trying to achieve?
> 
> Get real. (yes, i'm in a bad mood and i'm fond of stupid whining about
> 'Doctor, it hurts when i..'
> 
> Q:
> Dear X-mas whatever. I want this and that. Now. Immediately. No, i have
> no idea how to implement 'this' 'now', but it has to be done. What? Nah,
> no idea what 'this' nor 'that' nor 'now' is supposed to do, i'd have
> provided a guidance otherwise.
> A: alright. At your service.
> 
>> size I wanted to read. It would use ldrw instead of ldrh. So, It would 
>> help avoid those errors.
> 
> Try searching the archives for CPU selection (from memory, so may not be
> accurate) for further details.
>> Stuart
> 
> See below.
>> Tom wrote:
>>> I did think about adding -mcpu=<cpu> to the build CFLAGS, but that is
>>> not going to help with the problem that libgcc is not going to be 
>>> compiled correctly.
>>>
>> Why not? The kernel image, built with the same "incorrect" toolchain, 
>> must have used only ARMv4 instructions. If it hadn't, I would have never 
>> gotten far enough to even execute vprintf, libc. I would suspect that 
>> the kernel does a better job of setting -mcpu, -mtune. Thus these 
>> options should work for libc too. What makes you think that it wouldn't 
>> work for libc, have you tried? (PS: Even if it did, bug #1406 is 
>> probably the better fix, in particular as buildroot users might use its 
> 
> bug #1406 is completely crap. Let me cite:
> <quote>
>  Reporter  	 bjdooks
>  Summary  	 0001403: printf and anything using vfprintf() hangs
>  system
>  Description 	Any function using vfprintf, such as printf and snprintf
>  cause the system to stop. A test program shows that stdout is
>  functional, as fwrite() to stdout will display messages on the console
>  Additional Information 	uclibc 0.9.29
>  gcc 4.1.2 (arm-linux-uclibcgnueabi)
>  binutils 2.17.50.0.16
>  configure for ARM920T, EABI
> ---
> (0002514)
> bjdooks
> 06-25-07 17:26
> 
> 	The bug is still present in the development snapshot 
> ---
> (0002517)
> bjdooks
> 06-26-07 05:03
> 
> 	Building gcc 4.1.2 for OABI (patches will be sent in seperate
> 	report) does not work either.
> </quote>
>> toolchain to build their own code w/o always setting these options)
> 
> - No actual error shown.
> - no code/arch/toolchain hints to reproduce.
> This is one of the 'Doctor, it hurts'.. goto above;
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] ARM EABI builds

[Ben Dooks]

On Thu, Jun 28, 2007 at 06:00:30PM -0700, Tom wrote:
> 
> 
> 
> Bernhard Fischer wrote:
> > On Thu, Jun 28, 2007 at 03:54:22PM -0400, Stuart Wood wrote:
> >> Just a note on what Tom said about user land application. I've already 
> > 
> > Just as a note on what everybody seems to say about configuring GCC:
> > It is very amusing that you guys seem to be excited about _not_ setting
> > a config option -- CONFIG_BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS -- which
> > is specifically exported to you, to spell out specific requirements put
> > upon gcc (other toolchain parts of course also provide said means for
> > hand-crafted  options, mind you).
> 
> Speaking for myself, I am not excited about any particular option. Also 
> I don't need a doctor for this anymore, as for my part it works. Now.
> 
> However, as the combination EABI and ARM9 seems to be popular, I thought 
> it would be nice to save others some of this trouble that they are bound 
> to run into (*), either by just mentioning the option or by setting it 
> automatically in buildroot. If you are saying that 
> CONFIG_BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS is better suited for the 
> required target CPU option than BR2_EXTRA_GCC_CONFIG_OPTIONS, that could 
> very well be.
> 
> (*) This is the error I got after kernel boot on ARM920T/EABI default 
> config, w/o the required CPU option:
> init (1): undefined instruction: pc=00008c60

That is interesting, because I haven't been getting that when my
system fails. I'll check the setup of /dev/console and the /dev
entries for the serial ports. This would have been very helpful in
pointing out the problem. 

As an aside, it would be possible to fix the instruction in the
kernel's undefined instruction trap (as is done to emulate the
old hardware floating point instructions on newer processors) but
I personally feel that this is something the kernel should not
have to be doing.

[snip]

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[Buildroot] ARM EABI builds

[Alex Stewart]

Umm, I don't really know anything about Buildroot on ARM or EABI, but reading
through this discussion I did feel compelled to point out one thing I noticed:

On Fri, Jun 29, 2007 at 01:01:31AM +0200, Bernhard Fischer wrote:
> >work for libc, have you tried? (PS: Even if it did, bug #1406 is 
> >probably the better fix, in particular as buildroot users might use its 
> 
> bug #1406 is completely crap. Let me cite:
> <quote>
>  Reporter  	 bjdooks
>  Summary  	 0001403: printf and anything using vfprintf() hangs
>  system

As noted in the "Summary" line, the bug you quoted is 1403, not 1406.
Bug 1406 does appear to have a clear description of the issue and a proposed
patch to fix it, so while I can't comment on the merit of the patch contents,
the bug report itself, at least, does not appear to be "completely crap"..

-alex

[Buildroot] ARM EABI builds

[Bernhard Fischer]

On Thu, Jun 28, 2007 at 06:42:06PM -0700, Alex Stewart wrote:
>Umm, I don't really know anything about Buildroot on ARM or EABI, but reading
>through this discussion I did feel compelled to point out one thing I noticed:
>
>On Fri, Jun 29, 2007 at 01:01:31AM +0200, Bernhard Fischer wrote:
>> >work for libc, have you tried? (PS: Even if it did, bug #1406 is 

>>  Summary  	 0001403: printf and anything using vfprintf() hangs

>As noted in the "Summary" line, the bug you quoted is 1403, not 1406.

my bad.

>Bug 1406 does appear to have a clear description of the issue and a proposed
>patch to fix it, so while I can't comment on the merit of the patch contents,
>the bug report itself, at least, does not appear to be "completely crap"..

Yes, that one is ok.

[Buildroot] ARM EABI builds

[Ben Dooks]

On Fri, Jun 29, 2007 at 01:01:31AM +0200, Bernhard Fischer wrote:
> On Thu, Jun 28, 2007 at 03:54:22PM -0400, Stuart Wood wrote:
> >Just a note on what Tom said about user land application. I've already 
> 
> Just as a note on what everybody seems to say about configuring GCC:
> It is very amusing that you guys seem to be excited about _not_ setting
> a config option -- CONFIG_BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS -- which
> is specifically exported to you, to spell out specific requirements put
> upon gcc (other toolchain parts of course also provide said means for
> hand-crafted  options, mind you).

The point I was making in bug 1406, is that the config system already
asks you which cpu you are building for, and then does not pass it to
programs that use it, such as the compiler configuration. 
 
> >found that I had to add -march=armv4t to properly build my application, Just
> 
> doh!
> 
> >because gcc was not using the right load register code for the data 

you'll have also seen that libgcc.a has various optimisations in routines
such as the division/modulus helpers which use instructions like CLZ,
which only got added in ARMv5.

> well, if you don't tell it to do and _do not help in improving the
> generic situation_ how should we guess what you are trying to achieve?
> 
> Get real. (yes, i'm in a bad mood and i'm fond of stupid whining about
> 'Doctor, it hurts when i..'
> 
> Q:
> Dear X-mas whatever. I want this and that. Now. Immediately. No, i have
> no idea how to implement 'this' 'now', but it has to be done. What? Nah,
> no idea what 'this' nor 'that' nor 'now' is supposed to do, i'd have
> provided a guidance otherwise.
> A: alright. At your service.
> 
> >size I wanted to read. It would use ldrw instead of ldrh. So, It would 
> >help avoid those errors.
> 
> Try searching the archives for CPU selection (from memory, so may not be
> accurate) for further details.
> >
> >Stuart
> 
> See below.
> >
> >Tom wrote:
> >> 
> >> I did think about adding -mcpu=<cpu> to the build CFLAGS, but that is
> >> not going to help with the problem that libgcc is not going to be 
> >> compiled correctly.
> >> 
> >Why not? The kernel image, built with the same "incorrect" toolchain, 
> >must have used only ARMv4 instructions. If it hadn't, I would have never 
> >gotten far enough to even execute vprintf, libc. I would suspect that 
> >the kernel does a better job of setting -mcpu, -mtune. Thus these 
> >options should work for libc too. What makes you think that it wouldn't 
> >work for libc, have you tried? (PS: Even if it did, bug #1406 is 
> >probably the better fix, in particular as buildroot users might use its 
> 
> bug #1406 is completely crap. Let me cite:
> <quote>
>  Reporter  	 bjdooks
>  Summary  	 0001403: printf and anything using vfprintf() hangs

that's not bug 1406, looks like 1403 to me.

>  system
>  Description 	Any function using vfprintf, such as printf and snprintf
>  cause the system to stop. A test program shows that stdout is
>  functional, as fwrite() to stdout will display messages on the console
>  Additional Information 	uclibc 0.9.29
>  gcc 4.1.2 (arm-linux-uclibcgnueabi)
>  binutils 2.17.50.0.16
>  configure for ARM920T, EABI
> ---
> (0002514)
> bjdooks
> 06-25-07 17:26
> 
> 	The bug is still present in the development snapshot 
> ---
> (0002517)
> bjdooks
> 06-26-07 05:03
> 
> 	Building gcc 4.1.2 for OABI (patches will be sent in seperate
> 	report) does not work either.
> </quote>
> >toolchain to build their own code w/o always setting these options)
> 
> - No actual error shown.

I thought vfprintf() hangs is a pretty good error report, the system
did not give me any more information, and when you can't run init, then
it is very difficult to get gdb to do anything.

> - no code/arch/toolchain hints to reproduce.

I added details of the versions of the toolchain (gcc, uclibc) and the
ARM core being configured for ARM920T. Ok there was no .config attached
which wasn't helpful.

> This is one of the 'Doctor, it hurts'.. goto above;

ok, so not the world's best bug report, but after several days of
frustration with EABI not producing a working build, and OABI simply
not building a compiler, I was getting frustrated.

I finally got some inspiration from elsewhere, and decided to
disassemble libgcc.a and found the culprits in the div/mod code
and then set about trying to correct these.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.