[Buildroot] svn commit: trunk/uClibc: ldso/include ldso/ldso/sparc libc/string etc...

[Buildroot] svn commit: trunk/uClibc: ldso/include ldso/ldso/sparc libc/string etc...

[Bernhard Fischer]

On Sat, Sep 15, 2007 at 12:50:59AM -0700, vapier at uclibc.org wrote:
>Author: vapier
>Date: 2007-09-15 00:50:58 -0700 (Sat, 15 Sep 2007)
>New Revision: 19840
>
>Log:
>Blue Swirl writes:
>I got the library to compile with the attached patches, though dynamic
>loader crashes early.
>
>In buildroot I changed the architecture name by hand from sparc to
>sparc64, otherwise the compiler produced 32-bit files with V9 (64-bit)
>instructions. This configuration is not supported by QEMU, so I aimed
>for pure 64-bit. I think Sparc64 option needs to be added to
>buildroot.

http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi?rev=19853&view=rev

Blue Swirl, please let me know if that's correct and useable now.

TIA,
Bernhard

[Buildroot] svn commit: trunk/uClibc: ldso/include ldso/ldso/sparc libc/string etc...

[Bernhard Fischer]

On Sat, Sep 15, 2007 at 04:07:12PM +0300, Blue Swirl wrote:
>On 9/15/07, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
>> On Sat, Sep 15, 2007 at 12:50:59AM -0700, vapier at uclibc.org wrote:
>> >Author: vapier
>> >Date: 2007-09-15 00:50:58 -0700 (Sat, 15 Sep 2007)
>> >New Revision: 19840
>> >
>> >Log:
>> >Blue Swirl writes:
>> >I got the library to compile with the attached patches, though dynamic
>> >loader crashes early.
>> >
>> >In buildroot I changed the architecture name by hand from sparc to
>> >sparc64, otherwise the compiler produced 32-bit files with V9 (64-bit)
>> >instructions. This configuration is not supported by QEMU, so I aimed
>> >for pure 64-bit. I think Sparc64 option needs to be added to
>> >buildroot.
>>
>> http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi?rev=19853&view=rev
>>
>> Blue Swirl, please let me know if that's correct and useable now.
>
>The CPU selection could be improved so that for Sparc64, only the
>following are valid:
>config BR2_sparc_v9
>config BR2_sparc_ultrasparc
>config BR2_sparc_ultrasparc3
>config BR2_sparc_niagara

Ok, will do.

>I'm not so sure about removing those from Sparc(32) options, because
>then we could not build a 32-bit environment for V9 CPU.

In uClibc, we have v7, v8, v9, v9b (?).
What is the relation between insn-set/insn scheduler for these:
sparclite:      f930, f934, sparclite86x
sparclet:       tsc701
Are these all v8 (for uClibc)?

And what is v9b? An extended insn set or just v9 with a different
scheduling?

>I'm just trying a native build, looks like the compiler options build
>are not correct, there is -mcpu=v7 flag even though I selected v9.

Sounds odd, i'll look into this.

[Buildroot] svn commit: trunk/uClibc: ldso/include ldso/ldso/sparc libc/string etc...

[Blue Swirl]

On 9/15/07, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> On Sat, Sep 15, 2007 at 04:07:12PM +0300, Blue Swirl wrote:
> >On 9/15/07, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> >> On Sat, Sep 15, 2007 at 12:50:59AM -0700, vapier at uclibc.org wrote:
> >> >Author: vapier
> >> >Date: 2007-09-15 00:50:58 -0700 (Sat, 15 Sep 2007)
> >> >New Revision: 19840
> >> >
> >> >Log:
> >> >Blue Swirl writes:
> >> >I got the library to compile with the attached patches, though dynamic
> >> >loader crashes early.
> >> >
> >> >In buildroot I changed the architecture name by hand from sparc to
> >> >sparc64, otherwise the compiler produced 32-bit files with V9 (64-bit)
> >> >instructions. This configuration is not supported by QEMU, so I aimed
> >> >for pure 64-bit. I think Sparc64 option needs to be added to
> >> >buildroot.
> >>
> >> http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi?rev=19853&view=rev
> >>
> >> Blue Swirl, please let me know if that's correct and useable now.
> >
> >The CPU selection could be improved so that for Sparc64, only the
> >following are valid:
> >config BR2_sparc_v9
> >config BR2_sparc_ultrasparc
> >config BR2_sparc_ultrasparc3
> >config BR2_sparc_niagara
>
> Ok, will do.
>
> >I'm not so sure about removing those from Sparc(32) options, because
> >then we could not build a 32-bit environment for V9 CPU.
>
> In uClibc, we have v7, v8, v9, v9b (?).
> What is the relation between insn-set/insn scheduler for these:
> sparclite:      f930, f934, sparclite86x
> sparclet:       tsc701
> Are these all v8 (for uClibc)?

These are v7 (sparc32, early 1990s), the difference between v7 and v8
is that a few more instructions (div, mul) are implemented in hardware
in v8. I think kernel emulates the missing instructions (with a speed
penalty).

> And what is v9b? An extended insn set or just v9 with a different
> scheduling?

V9 plus VIS (much like MMX) instructions, like falignaddr and
aligndata used in libc/string/sparc/sparc64/memcpy.S. That by the way
makes it difficult to target plain V9...

> >I'm just trying a native build, looks like the compiler options build
> >are not correct, there is -mcpu=v7 flag even though I selected v9.
>
> Sounds odd, i'll look into this.
>

Sorry, I think it was "k7" for cross compile host in the other window, not v7.

[Buildroot] svn commit: trunk/uClibc: ldso/include ldso/ldso/sparc libc/string etc...

[Bernhard Fischer]

On Sat, Sep 15, 2007 at 10:41:51PM +0300, Blue Swirl wrote:

>> >> Blue Swirl, please let me know if that's correct and useable now.
>> >
>> >The CPU selection could be improved so that for Sparc64, only the
>> >following are valid:
>> >config BR2_sparc_v9
>> >config BR2_sparc_ultrasparc
>> >config BR2_sparc_ultrasparc3
>> >config BR2_sparc_niagara
>>
>> Ok, will do.
>>
>> >I'm not so sure about removing those from Sparc(32) options, because
>> >then we could not build a 32-bit environment for V9 CPU.
>>
>> In uClibc, we have v7, v8, v9, v9b (?).
>> What is the relation between insn-set/insn scheduler for these:
>> sparclite:      f930, f934, sparclite86x
>> sparclet:       tsc701
>> Are these all v8 (for uClibc)?
>
>These are v7 (sparc32, early 1990s), the difference between v7 and v8
>is that a few more instructions (div, mul) are implemented in hardware
>in v8. I think kernel emulates the missing instructions (with a speed
>penalty).
>
>> And what is v9b? An extended insn set or just v9 with a different
>> scheduling?
>
>V9 plus VIS (much like MMX) instructions, like falignaddr and
>aligndata used in libc/string/sparc/sparc64/memcpy.S. That by the way
>makes it difficult to target plain V9...
>
>> >I'm just trying a native build, looks like the compiler options build
>> >are not correct, there is -mcpu=v7 flag even though I selected v9.
>>
>> Sounds odd, i'll look into this.
>>
>
>Sorry, I think it was "k7" for cross compile host in the other window, not v7.

Ok. I've split sparc64 from sparc, added a pseudo v9b that turns on
-mvis, made sure that configuring uClibc picks up the correct type.
Please holler if i made something wrong or if you need additional bits..

cheers,
Bernhard

[Buildroot] sparc64 v9 VIS toolchain bug with fzeros?

[Bernhard Fischer]

Hi Blue Swirl,

Configuring gcc with --with-tune=v9 and -mvis in cflags, how can there
be a call to fzeros (a v9a instruction, from the looks)?

Specifically, i see:
/tmp/buildroot_trunk/build_sparc64/staging_dir/usr/bin/sparc64-linux-uclibc-gcc 
-Os -I/tmp/buildroot_trunk/build_sparc64/staging_dir/usr/include
-I/tmp/buildroot_trunk/build_sparc64/staging_dir/include
--sysroot=/tmp/buildroot_trunk/build_sparc64/staging_dir/ -isysroot
/tmp/buildroot_trunk/build_sparc64/staging_dir -mtune=v9 -mvis
-DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include  -D_GNU_SOURCE
-DNDEBUG -O2 -fPIC -c ../ncurses/./tty/lib_mvcur.c -o
../obj_s/lib_mvcur.o
{standard input}: Assembler messages:
{standard input}:12791: Error: Architecture mismatch on "fzeros".
{standard input}:12791:  (Requires v9a|v9b; requested architecture is v9.)
make[2]: *** [../obj_s/lib_mvcur.o] Error 1
make[2]: Leaving directory `/tmp/buildroot_trunk/build_sparc64/ncurses-5.6/ncurses'

Is this a bug in binutils-2.17.50.0.17/gcc-4.2.1 or is my configuration wrong?

[Buildroot] sparc64 v9 VIS toolchain bug with fzeros?

[Blue Swirl]

On 9/17/07, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> Configuring gcc with --with-tune=v9 and -mvis in cflags, how can there
> be a call to fzeros (a v9a instruction, from the looks)?

You specified -mvis. The instruction set is like this:
v9 = no vis
v9a = v9 + vis 1
v9b = v9a + vis 2