Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[loody]

> Why is only supporting FLAT a problem for you?
> (It is not entirely true to say uClinux only supports FLAT,
> some uClinux architectures support fdelf-pic).

Sorry for using the word, ONLY. Tears will make the screen blur, you
know.   :-(....

>
>
>> I don't know how to make a flat with the arm-linux compiler linked
>> from uclinux.org. You can see it in the previous letter.
>
> That is why I said to get the uClinux-dist.
> It builds applications with that compiler against its
> own uClibc. They work. I specifically test it for the
> GDB/ARMulator target before uClinux-dist releases.
>

According all your suggestions, I stop trying to use different
cross-toolchains except
1. arm-linux-tools-20061213.tar.gz
2. arm-linux-tools-20070808.tar.gz

And I try to use both of them to compile applications at user.
2 can get the FLAT I need but 1 will fail while calling the linker and it says
ld.real: address 0x22380 of busybox_unstripped.gdb section .text is
not within region flatmem

So I wipe my tears out and recompile the kernel with 2 happily :)
but tears full fill my eyes again when my platform get
unknown-instruction-exception, while executing below instructions:

   e1a0e00f        mov     lr, pc
   e12fff13        bx      r3

 :-(~~~

There are 2 ways come to my mind to solve this problem:
a. find out why 1 cannot transform the flat successfully and I need
someone who familiar with ld to help me.
b. check why 2 will make my platform get unknown-instruction-exception.
     2, buildroot and Codesourcery-toolchain all will let this happen.
     I guess the culprit is gcc 4.2xxxxx, since 1 use gcc 3.3xxxx.
     Jamie gives me some directions and I am still working on it.
     Is there any specific compile option in 4.2 and 3.3 will let this happen?
     What is the specialty of the instruction, "mov lr,pc", which let
arm cpu fail?

 appreciate your help and consolation,
miloody

Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[Jamie Lokier]

loody wrote:
>    e1a0e00f        mov     lr, pc
>    e12fff13        bx      r3

>      What is the specialty of the instruction, "mov lr,pc", which let
> arm cpu fail?

Both of those instructions can put the CPU into Thumb mode.  If it
doesn't support Thumb, you get an instruction fault.

"mov lr,pc" is supported on all ARMs, but (guessing from what you're
getting) maybe it can fault depending on the value in "lr"?

"bx" is not available on all ARMs, and will fault when you don't have
it.  That's why it's necessary to build everything with the right GCC
options.

I wouldn't be surprised if the Codesourcery tools (especially
pre-built libs) are targetting later ARM chips only, since people
using later ARM chips are probably paying Codesourcery for the work.

-- Jamie

Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[loody]

2009/1/29 Jamie Lokier <jamie@shareable.org>:
> loody wrote:
>>    e1a0e00f        mov     lr, pc
>>    e12fff13        bx      r3
>
>>      What is the specialty of the instruction, "mov lr,pc", which let
>> arm cpu fail?
>
> Both of those instructions can put the CPU into Thumb mode.  If it
> doesn't support Thumb, you get an instruction fault.
>
> "mov lr,pc" is supported on all ARMs, but (guessing from what you're
> getting) maybe it can fault depending on the value in "lr"?

Hi:
I cannot understand the meaning of depending the value in "lr"?
Actually my cpu get exception when executing this instruction not bx r3.
But lr is the destination for cpu to write, I have checked the arm
reference and it doesn't say any cautions when the destination is lr.

>
> "bx" is not available on all ARMs, and will fault when you don't have
> it.  That's why it's necessary to build everything with the right GCC
> options.

There are bx instructions generated when I use arm-linux-2006.
I list them below:

800096a0 <__kuser_helper_start>:
800096a0:       e12fff1e        bx      lr
        ...

800096c0 <__kuser_cmpxchg>:
800096c0:       e3e00000        mvn     r0, #0  ; 0x0
800096c4:       e2900000        adds    r0, r0, #0      ; 0x0
800096c8:       e12fff1e        bx      lr
        ...

800096e0 <__kuser_get_tls>:
800096e0:       ee1d0f70        mrc     15, 0, r0, cr13, cr0, {3}
800096e4:       e12fff1e        bx      lr


BTW, can I take off the Thumb support in my compiler options?
Thumb is only used for decreasing the density of source code and so
far I just want my kernel say hello to me.
appreciate your help,
miloody

Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[Jamie Lokier]

loody wrote:
> 2009/1/29 Jamie Lokier <jamie@shareable.org>:
> > loody wrote:
> >>    e1a0e00f        mov     lr, pc
> >>    e12fff13        bx      r3
>
> Actually my cpu get exception when executing this instruction not bx r3.
> But lr is the destination for cpu to write, I have checked the arm
> reference and it doesn't say any cautions when the destination is lr.

You're right, that doesn't make sense to me either.

> > "bx" is not available on all ARMs, and will fault when you don't have
> > it.  That's why it's necessary to build everything with the right GCC
> > options.
> 
> There are bx instructions generated when I use arm-linux-2006.
> 
> BTW, can I take off the Thumb support in my compiler options?
> Thumb is only used for decreasing the density of source code and so
> far I just want my kernel say hello to me.

At this point, you may want to subscribe to the linux-arm mailing
list, and ask the question again there :-)

    http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm

-- Jamie

Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[Daniel Jacobowitz]

On Thu, Jan 29, 2009 at 06:12:15AM +0000, Jamie Lokier wrote:
> I wouldn't be surprised if the Codesourcery tools (especially
> pre-built libs) are targetting later ARM chips only, since people
> using later ARM chips are probably paying Codesourcery for the work.

Our tools support all (post-V4) ARM processors; I believe that we
package libraries for all processors too nowadays.  The defaults may
be fairly modern, though - so as Jamie said, be sure to tell the tools
what you want your code to run on!

-- 
Daniel Jacobowitz
CodeSourcery

Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[Jamie Lokier]

Daniel Jacobowitz wrote:
> On Thu, Jan 29, 2009 at 06:12:15AM +0000, Jamie Lokier wrote:
> > I wouldn't be surprised if the Codesourcery tools (especially
> > pre-built libs) are targetting later ARM chips only, since people
> > using later ARM chips are probably paying Codesourcery for the work.
> 
> Our tools support all (post-V4) ARM processors; I believe that we
> package libraries for all processors too nowadays.  The defaults may
> be fairly modern, though - so as Jamie said, be sure to tell the tools
> what you want your code to run on!

ARM has a huge number of instruction set variants.  This is a quick
guess, I'm no expert (but I've already been daunted when looking into
ARM FDPIC-ELF, simply at the number of different ways jumps and calls
are encoded)):

    { OABI, EABI soft-float, EABI hard-float }
                     times
    { ARMv4, ARMv4T, ARMv5, ARMv6, ARMv7 (?) }
                     times
            { not Thumb, Thumb, Thumb2 }
                     times
             { Thumb interwork or not }
                     times
         { non-PIC, PIC, PIC+single-pic-base }

Do you really have a policy of including pre-built multilib-ed libc
and libstdc++ as well as libgcc for all the combinations that make
sense?

My approach these days is to build all libraries including libgcc
specifically targetted at the CPU variant being used by whatever
projected I'm using.  It saves headaches from things that crash
spontaneously otherwise.  I haven't tried the Codesourcery ARM tools
yet, though I intended to soon.

-- Jamie

Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[Daniel Jacobowitz]

Closed list CC removed.

On Thu, Jan 29, 2009 at 06:50:46PM +0000, Jamie Lokier wrote:
> Do you really have a policy of including pre-built multilib-ed libc
> and libstdc++ as well as libgcc for all the combinations that make
> sense?

Yes, but that's fewer than you think.

I don't know off the top of my head which libraries we ship.  But all
our tools are EABI; and one of the explicit goals of the EABI is to
reduce the number of link-incompatible variants.  Others are often
*desirable*, and we obviously ship more than the bare minimum.

We've also made the linker Very Smart(TM) at detecting incompatible
objects, based on ABI-specified object attributes.

>     { OABI, EABI soft-float, EABI hard-float }
>                      times

EABI soft and hard float are link compatible.  There's an
incompatible variant of the EABI that uses hardware registers for
arguments in addition to for calculation; GCC will not support it
until 4.5 though.

>              { Thumb interwork or not }
>                      times

The EABI mandates interworking.  Linker fixups are used to accomodate
v4; there is an important performance distinction between v4-T and v5
though.

>     { ARMv4, ARMv4T, ARMv5, ARMv6, ARMv7 (?) }
>                      times

All common-denominator compatible.

>             { not Thumb, Thumb, Thumb2 }
>                      times

All compatible.

>          { non-PIC, PIC, PIC+single-pic-base }

PIC and non-PIC are compatible.  I'm not familiar with
single-pic-base, since there's no existing ARM FDPIC and we do not do
a lot of work with other systems that use a single-pic-base.

-- 
Daniel Jacobowitz
CodeSourcery