Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[H Hartley Sweeten]

Hello Yann,

I did not get a CC on your reply but saw it in the mail archive.  Hopefully
this gets threaded correctly...

> On Tuesday 08 September 2009 22:42:24 H Hartley Sweeten wrote:
>> I have been trying to get CodeSourcery's arm-none-linux-gnueabi (Sourcery
>> G++ Lite 2009q1-203) 4.3.3 toolchain to work with Buildroot and an EP93xx
>> based target. ÂUnfortunately Buildroot is not setup to handle the multilib
>> feature of that toolchain (default libraries are for ARMv5T). ÂI have
>> tried a number of ways in Buildroot to get that that toolchain to work but
>> my resulting filesystem always dies due to an unrecognized instruction.
>
> If we can trust the Linux kernel, then the EP93xx is an arm920t, which
> is an armv4, not an armv5t. Which can explain why you have an illegal
> instruction...

The Linux kernel was getting compiled correctly with the CodeSourcery
toolchain so we can probably trust it.  I have been using that toolchain
for a number of months to build my kernel.  I only ran into a problem with
Buildroot when I tried rebuilding my filesystem a couple of weeks ago.

I have manually compiled a static test "init" program for my filesystem and
it ran without issues.  I think the only problem with the CodeSourcery
toolchain is that Buildroot does not understand how to handle the multilib
aspect of it.

I'm hoping that a sysroot toolchain that only supports "my" architecture
will work better with Buildroot.

>> I followed the Download and usage instructions on the website:
> [--SNIP install steps--]
>
> Correct. :-)

Well at least I did that right. ;-)

>> I think I have everything setup and configured correctly but I can't figure
>> out why the build is failing.  From the build.log it appears that linuxthreads
>> is getting checked out but when the build tries to mv it the files do not exist:
>> [ALL  ]    cvs checkout: Updating linuxthreads/linuxthreads_db
>> [DEBUG]    ==> Executing: 'mv linuxthreads glibc-linuxthreads-cvs-2.7'
>> [ALL  ]    mv: cannot stat `linuxthreads': No such file or directory
>> [ERROR]    Build failed in step 'Retrieving needed toolchain components' tarballs'
>
> I don't download everything every time, so it may well be that something
> broke at some point. Care to send your .config, so I can try to reproduce?

I tried executing the command line that fails from the build.log directly.

bigguiness@etch:~/src/tmp$ cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc co -P -r glibc-2_6-branch linuxthreads
cvs checkout: CVS password file /home/bigguiness/.cvspass does not exist - creating a new file
cvs checkout: Updating linuxthreads
[--SNIP more cvs checkout lines--]
cvs checkout: Updating linuxthreads/linuxthreads_db
bigguiness@etch:~/src/tmp$ ls
bigguiness@etch:~/src/tmp$

It appears that the checkout is not working correctly.

My .config follows at the end of this message.

>> Do I have something configured incorrectly or am I doing something wrong?
>> Is there a "magic" combination of the Binutils/C compiler/C-library version
>> that must be used?
>
> There's no armv4t sample in crosstool-NG.
> But you could base your configuration on the arm-unknown-linux-uclibc
> sample, and update the configuration to something like:
>   Target options -->
>     (armv4t) Architecture level
>     ()  Generate code for the specific ABI
>     (ep9312) Emit assembly for CPU
>     (ep9312) Tune for CPU
>     (maverick) Use specific FPU
>     Floating point: ---> hardware (FPU)
> 
> NB: do not enable EABI, I think it requires at least armv5t, but I'm
>     not sure. So stay on the safe side, and stick with OABI.

I set those options.  I used arm920t instead of ep9312 but I believe
ep9312 is just an alias.

BTW, EABI does work on the armv4t.  My kernel is compiled with it and
works with no problems.

> I give no guarantee, as I don't have the HW, but you should give it a
> try. Also, java is currently broken, so you should disable it in the
> "C compiler" sub-menu...

I don't need java so that's not a problem.  I already have it disabled in
The options.

Thanks,
Hartley

---

#
# Automatically generated make config: don't edit
# crosstool-NG version: hg_default@1523_6c2a6c04187e
# Tue Sep  8 13:11:53 2009
#

#
# Paths and misc options
#

#
# crosstool-NG behavior
#
# CT_OBSOLETE is not set
# CT_EXPERIMENTAL is not set
# CT_DEBUG_CT is not set

#
# Paths
#
CT_LOCAL_TARBALLS_DIR="/home/bigguiness/dl"
CT_SAVE_TARBALLS=y
CT_WORK_DIR="${CT_TOP_DIR}/targets"
CT_PREFIX_DIR="${HOME}/x-tools/${CT_TARGET}"
CT_INSTALL_DIR="${CT_PREFIX_DIR}"
CT_REMOVE_DOCS=y
CT_INSTALL_DIR_RO=y

#
# Downloading
#
# CT_FORBID_DOWNLOAD is not set
# CT_FORCE_DOWNLOAD is not set
# CT_USE_MIRROR is not set
CT_CONNECT_TIMEOUT=10
# CT_ONLY_DOWNLOAD is not set

#
# Extracting
#
# CT_FORCE_EXTRACT is not set
CT_OVERIDE_CONFIG_GUESS_SUB=y
# CT_ONLY_EXTRACT is not set
CT_PATCH_BUNDLED=y
# CT_PATCH_LOCAL is not set
# CT_PATCH_BUNDLED_LOCAL is not set
# CT_PATCH_LOCAL_BUNDLED is not set
# CT_PATCH_BUNDLED_FALLBACK_LOCAL is not set
# CT_PATCH_LOCAL_FALLBACK_BUNDLED is not set
CT_PATCH_ORDER="bundled"
# CT_PATCH_SINGLE is not set
# CT_PATCH_USE_LOCAL is not set

#
# Build behavior
#
CT_PARALLEL_JOBS=1
CT_LOAD=0
CT_NICE=0
CT_USE_PIPES=y
# CT_CONFIG_SHELL_SH is not set
# CT_CONFIG_SHELL_ASH is not set
CT_CONFIG_SHELL_BASH=y
# CT_CONFIG_SHELL_CUSTOM is not set
CT_CONFIG_SHELL="bash"

#
# Logging
#
# CT_LOG_ERROR is not set
# CT_LOG_WARN is not set
CT_LOG_INFO=y
# CT_LOG_EXTRA is not set
# CT_LOG_DEBUG is not set
# CT_LOG_ALL is not set
CT_LOG_LEVEL_MAX="INFO"
# CT_LOG_SEE_TOOLS_WARN is not set
CT_LOG_PROGRESS_BAR=y
CT_LOG_TO_FILE=y
CT_LOG_FILE_COMPRESS=y

#
# Target options
#
CT_ARCH="arm"
# CT_ARCH_64 is not set
# CT_ARCH_SUPPORTS_BOTH_MMU is not set
CT_ARCH_SUPPORTS_BOTH_ENDIAN=y
CT_ARCH_SUPPORT_ARCH=y
# CT_ARCH_SUPPORT_ABI is not set
CT_ARCH_SUPPORT_CPU=y
CT_ARCH_SUPPORT_TUNE=y
CT_ARCH_SUPPORT_FPU=y
# CT_ARCH_DEFAULT_HAS_MMU is not set
# CT_ARCH_DEFAULT_BE is not set
CT_ARCH_DEFAULT_LE=y
CT_ARCH_ARCH="armv4t"
CT_ARCH_CPU="arm920t"
CT_ARCH_TUNE="arm920t"
CT_ARCH_FPU="maverick"
# CT_ARCH_BE is not set
CT_ARCH_LE=y
# CT_ARCH_FLOAT_HW is not set
CT_ARCH_FLOAT_SW=y
CT_TARGET_CFLAGS=""
CT_TARGET_LDFLAGS=""

#
# General target options
#
# CT_ARCH_alpha is not set
CT_ARCH_arm=y
# CT_ARCH_avr32 is not set
# CT_ARCH_ia64 is not set
# CT_ARCH_mips is not set
# CT_ARCH_powerpc64 is not set
# CT_ARCH_powerpc is not set
# CT_ARCH_sh is not set
# CT_ARCH_x86_64 is not set
# CT_ARCH_x86 is not set
CT_ARCH_ARM_EABI=y
CT_ARCH_USE_MMU=y

#
# Target optimisations
#

#
# Toolchain options
#

#
# General toolchain options
#
CT_USE_SYSROOT=y
CT_SYSROOT_DIR_PREFIX=""

#
# Tuple completion and aliasing
#
CT_TARGET_VENDOR="unknown"
CT_TARGET_ALIAS_SED_EXPR=""
CT_TARGET_ALIAS=""

#
# Toolchain type
#
# CT_NATIVE is not set
CT_CROSS=y
# CT_CROSS_NATIVE is not set
# CT_CANADIAN is not set
CT_TOOLCHAIN_TYPE="cross"

#
# Build system
#
CT_BUILD=""
CT_BUILD_PREFIX=""
CT_BUILD_SUFFIX=""

#
# Operating System
#
# CT_BARE_METAL is not set
CT_KERNEL_SUPPORTS_SHARED_LIBS=y
CT_KERNEL="linux"
CT_KERNEL_VERSION="2.6.27.31"
# CT_KERNEL_bare_metal is not set
CT_KERNEL_linux=y
CT_KERNEL_LINUX_INSTALL=y
CT_KERNEL_LINUX_INSTALL_CHECK=y
# CT_KERNEL_V_2_6_18_8 is not set
# CT_KERNEL_V_2_6_19_7 is not set
# CT_KERNEL_V_2_6_20_21 is not set
# CT_KERNEL_V_2_6_21_7 is not set
# CT_KERNEL_V_2_6_22_19 is not set
# CT_KERNEL_V_2_6_23_17 is not set
# CT_KERNEL_V_2_6_24_7 is not set
# CT_KERNEL_V_2_6_25_20 is not set
# CT_KERNEL_V_2_6_26_8 is not set
CT_KERNEL_V_2_6_27_31=y
# CT_KERNEL_V_2_6_28_10 is not set
# CT_KERNEL_V_2_6_29 is not set
# CT_KERNEL_V_2_6_29_1 is not set
# CT_KERNEL_V_2_6_29_2 is not set
# CT_KERNEL_V_2_6_29_3 is not set
# CT_KERNEL_V_2_6_29_4 is not set
# CT_KERNEL_V_2_6_29_5 is not set
# CT_KERNEL_V_2_6_29_6 is not set
# CT_KERNEL_V_2_6_30 is not set
# CT_KERNEL_V_2_6_30_1 is not set
# CT_KERNEL_V_2_6_30_2 is not set
# CT_KERNEL_V_2_6_30_3 is not set
# CT_KERNEL_V_2_6_30_4 is not set
# CT_KERNEL_V_2_6_30_5 is not set
# CT_KERNEL_V_select is not set
CT_KERNEL_LINUX_VERBOSITY_0=y
# CT_KERNEL_LINUX_VERBOSITY_1 is not set
# CT_KERNEL_LINUX_VERBOSITY_2 is not set
CT_KERNEL_LINUX_VERBOSE_LEVEL=0
# CT_KERNEL_LINUX_USE_CUSTOM_HEADERS is not set

#
# Common kernel options
#
CT_SHARED_LIBS=y

#
# Binary utilities
#
CT_ARCH_BINFMT_ELF=y
# CT_ARCH_BINFMT_FLAT is not set

#
# GNU binutils
#
CT_BINUTILS_VERSION="2.19.1"
# CT_BINUTILS_V_2_14 is not set
# CT_BINUTILS_V_2_15 is not set
# CT_BINUTILS_V_2_16_1 is not set
# CT_BINUTILS_V_2_17 is not set
# CT_BINUTILS_V_2_18 is not set
# CT_BINUTILS_V_2_18_50_0_4 is not set
# CT_BINUTILS_V_2_18_50_0_6 is not set
# CT_BINUTILS_V_2_18_50_0_7 is not set
# CT_BINUTILS_V_2_18_50_0_8 is not set
# CT_BINUTILS_V_2_18_50_0_9 is not set
# CT_BINUTILS_V_2_18_90 is not set
# CT_BINUTILS_V_2_18_91 is not set
# CT_BINUTILS_V_2_18_92 is not set
# CT_BINUTILS_V_2_18_93 is not set
# CT_BINUTILS_V_2_19 is not set
CT_BINUTILS_V_2_19_1=y
# CT_BINUTILS_V_2_19_50_0_1 is not set
# CT_BINUTILS_V_2_19_51_0_1 is not set
# CT_BINUTILS_V_2_19_51_0_2 is not set
CT_BINUTILS_EXTRA_CONFIG=""
# CT_BINUTILS_FOR_TARGET is not set

#
# C compiler
#
CT_CC="gcc"
CT_CC_VERSION="4.3.4"
CT_CC_gcc=y
# CT_CC_V_3_2_3 is not set
# CT_CC_V_3_3_6 is not set
# CT_CC_V_3_4_6 is not set
# CT_CC_V_4_0_0 is not set
# CT_CC_V_4_0_1 is not set
# CT_CC_V_4_0_2 is not set
# CT_CC_V_4_0_3 is not set
# CT_CC_V_4_0_4 is not set
# CT_CC_V_4_1_0 is not set
# CT_CC_V_4_1_1 is not set
# CT_CC_V_4_1_2 is not set
# CT_CC_V_4_2_0 is not set
# CT_CC_V_4_2_1 is not set
# CT_CC_V_4_2_2 is not set
# CT_CC_V_4_2_3 is not set
# CT_CC_V_4_2_4 is not set
# CT_CC_V_4_3_0 is not set
# CT_CC_V_4_3_1 is not set
# CT_CC_V_4_3_2 is not set
# CT_CC_V_4_3_3 is not set
CT_CC_V_4_3_4=y
# CT_CC_V_4_4_0 is not set
# CT_CC_V_4_4_1 is not set
CT_CC_GCC_4_3_or_later=y
# CT_CC_GCC_4_4_or_later is not set
CT_CC_CXA_ATEXIT=y
CT_CC_SJLJ_EXCEPTIONS_CONFIGURE=y
# CT_CC_SJLJ_EXCEPTIONS_USE is not set
# CT_CC_SJLJ_EXCEPTIONS_DONT_USE is not set
CT_CC_ENABLE_CXX_FLAGS=""
CT_CC_CORE_EXTRA_CONFIG=""
CT_CC_EXTRA_CONFIG=""
CT_CC_PKGVERSION="crosstool-NG-${CT_VERSION}"
CT_CC_BUGURL=""
CT_CC_SUPPORT_CXX=y
CT_CC_SUPPORT_FORTRAN=y
CT_CC_SUPPORT_JAVA=y
CT_CC_SUPPORT_ADA=y
CT_CC_SUPPORT_OBJC=y
CT_CC_SUPPORT_OBJCXX=y

#
# Additional supported languages:
#
CT_CC_LANG_CXX=y
# CT_CC_LANG_FORTRAN is not set
# CT_CC_LANG_JAVA is not set
CT_LIBC="glibc"

#
# C-library
#
CT_LIBC_VERSION="2.7"
# CT_LIBC_eglibc is not set
CT_LIBC_glibc=y
# CT_LIBC_newlib is not set
# CT_LIBC_uClibc is not set
# CT_LIBC_V_2_3_6 is not set
# CT_LIBC_V_2_5 is not set
# CT_LIBC_V_2_5_1 is not set
# CT_LIBC_V_2_6 is not set
# CT_LIBC_V_2_6_1 is not set
CT_LIBC_V_2_7=y
# CT_LIBC_V_2_8 is not set
# CT_LIBC_V_2_9 is not set
# CT_LIBC_V_LATEST is not set
# CT_LIBC_V_date is not set
# CT_LIBC_GLIBC_2_8_or_later is not set
# CT_LIBC_GLIBC_TARBALL is not set
CT_LIBC_GLIBC_CVS=y
CT_LIBC_GLIBC_CVS_date=""

#
# glibc/eglibc common options
#
CT_LIBC_GLIBC_EXTRA_CONFIG=""
CT_LIBC_GLIBC_CONFIGPARMS=""
CT_LIBC_GLIBC_EXTRA_CFLAGS=""
CT_LIBC_EXTRA_CC_ARGS=""
CT_LIBC_GLIBC_USE_PORTS=y
CT_LIBC_ADDONS_LIST=""
# CT_LIBC_GLIBC_KERNEL_VERSION_NONE is not set
CT_LIBC_GLIBC_KERNEL_VERSION_AS_HEADERS=y
# CT_LIBC_GLIBC_KERNEL_VERSION_CHOSEN is not set
CT_LIBC_GLIBC_MIN_KERNEL="2.6.27.31"

#
# Common C library options
#
CT_LIBC_SUPPORT_NPTL=y
CT_LIBC_SUPPORT_LINUXTHREADS=y
CT_THREADS="linuxthreads"
# CT_THREADS_NPTL is not set
CT_THREADS_LINUXTHREADS=y
# CT_THREADS_NONE is not set

#
# Debug facilities
#
# CT_DEBUG_dmalloc is not set
# CT_DEBUG_duma is not set
# CT_DEBUG_gdb is not set
# CT_DEBUG_ltrace is not set
# CT_DEBUG_strace is not set

#
# Tools facilities
#
# CT_TOOL_libelf is not set
# CT_TOOL_sstrip is not set

#
# Companion libraries
#
CT_WRAPPER_NEEDED=y
CT_GMP_MPFR=y
CT_GMP_V_4_2_2=y
# CT_GMP_V_4_2_4 is not set
# CT_GMP_V_4_3_0 is not set
# CT_GMP_V_4_3_1 is not set
CT_GMP_VERSION="4.2.2"
CT_MPFR_V_2_3_1=y
# CT_MPFR_V_2_3_2 is not set
# CT_MPFR_V_2_4_0 is not set
# CT_MPFR_V_2_4_1 is not set
CT_MPFR_VERSION="2.3.1"
# CT_PPL_CLOOG_MPC is not set

#
# Companion libraries common options
#
# CT_COMP_LIBS_CHECK is not set
# CT_COMP_LIBS_TARGET is not set
CT_TOOLS_WRAPPER_SCRIPT=y
# CT_TOOLS_WRAPPER_EXEC is not set
CT_TOOLS_WRAPPER="script"

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Martin Guy]

>  >     (maverick) Use specific FPU
>  >     Floating point: ---> hardware (FPU)

Don't do that! :) Mainline GCC's code generation for Maverick is
completely broken, glibc needs patches, binutils barfs on some GCC
output for C++, and the FPU itself is full of hardware timing bugs
that GCC fails miserably to work around.
I have a set of working GCC patches for C, and OE have collected the
glibc and binutils patches but I've never heard of anyone getting a
fully working rootfs yet.

>  > NB: do not enable EABI, I think it requires at least armv5t, but I'm
>  >     not sure. So stay on the safe side, and stick with OABI.

EABI requires armv4t. The only thing v5t has at an ISA level is an
extra instruction, count leading zeros, which is used in glibc's asm
division routine ifdef armv5t. armv4t would have been a better GCC
default.
I think we can safely ditch OABI these days, unless you have an armv4
(the StrongARM) or armv3. It has no technical advantages, and most
programs that had bugs needing fixing have now been fixed. There are a
few stragglers: gnat ADA, clisp common lisp, fpc free pascal compiler
and any version of GCC <4.1.0

> I used arm920t instead of ep9312 but I believe
> ep9312 is just an alias.
for arm920t, yes. It also passes "armv4t+maverick" to the assembler so
that maverick insns are not rejected by the assembler. (cpu=arm920t
fpu=maverick makes the assembler barf. Yes, this is a mess!)

    M

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

RE: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[H Hartley Sweeten]

On Wednesday, September 09, 2009 4:01 AM, Martin Guy wrote:
>>>     (maverick) Use specific FPU
>>>     Floating point: ---> hardware (FPU)
>
> Don't do that! :) Mainline GCC's code generation for Maverick is
> completely broken, glibc needs patches, binutils barfs on some GCC
> output for C++, and the FPU itself is full of hardware timing bugs
> that GCC fails miserably to work around.
> I have a set of working GCC patches for C, and OE have collected the
> glibc and binutils patches but I've never heard of anyone getting a
> fully working rootfs yet.

OK.  I removed the "maverick" setting and set the Floating point to
software.

>>> NB: do not enable EABI, I think it requires at least armv5t, but I'm
>>>     not sure. So stay on the safe side, and stick with OABI.
>
> EABI requires armv4t. The only thing v5t has at an ISA level is an
> extra instruction, count leading zeros, which is used in glibc's asm
> division routine ifdef armv5t. armv4t would have been a better GCC
> default.

I agree.  Would have made my life easier with the CodeSourcery toolchain. ;-)

> I think we can safely ditch OABI these days, unless you have an armv4
> (the StrongARM) or armv3. It has no technical advantages, and most
> programs that had bugs needing fixing have now been fixed. There are a
> few stragglers: gnat ADA, clisp common lisp, fpc free pascal compiler
> and any version of GCC <4.1.0
> 
>> I used arm920t instead of ep9312 but I believe ep9312 is just an alias.
> for arm920t, yes. It also passes "armv4t+maverick" to the assembler so
> that maverick insns are not rejected by the assembler. (cpu=arm920t
> fpu=maverick makes the assembler barf. Yes, this is a mess!)

So with "arm920t" does the assembler work ok for the ep93xx or should it
be "ep9312"?

What should my target options be for the ep93xx?  Right now I have:

CT_ARCH="arm"
CT_ARCH_SUPPORTS_BOTH_ENDIAN=y
CT_ARCH_SUPPORT_ARCH=y
CT_ARCH_SUPPORT_CPU=y
CT_ARCH_SUPPORT_TUNE=y
CT_ARCH_SUPPORT_FPU=y
CT_ARCH_DEFAULT_LE=y
CT_ARCH_ARCH="armv4t"
CT_ARCH_CPU="arm920t"
CT_ARCH_TUNE="arm920t"
CT_ARCH_FPU=""
CT_ARCH_LE=y
CT_ARCH_FLOAT_SW=y
CT_TARGET_CFLAGS=""
CT_TARGET_LDFLAGS=""

Thanks for any help!

Regards,
Hartley

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[wino]

  On Wednesday, September 09, 2009 4:01 AM, Martin Guy wrote:
>>>>     (maverick) Use specific FPU
>>>>     Floating point: ---> hardware (FPU)
>> Don't do that! :) Mainline GCC's code generation for Maverick is
>> completely broken, glibc needs patches, binutils barfs on some GCC
>> output for C++, and the FPU itself is full of hardware timing bugs
>> that GCC fails miserably to work around.
>> I have a set of working GCC patches for C, and OE have collected the
>> glibc and binutils patches but I've never heard of anyone getting a
>> fully working rootfs yet.
> 
Hi,
would it be possible to provide links to these patch sets so that they 
could be included in ct-ng?

IIRC you recommend 4.2.2 rather than 4.3.x , is that correct?

regards.


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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Martin Guy]

On 9/9/09, H Hartley Sweeten <hartleys@visionengravers.com> wrote:
>  >> I used arm920t instead of ep9312 but I believe ep9312 is just an alias.
>  > for arm920t, yes. It also passes "armv4t+maverick" to the assembler
> So with "arm920t" does the assembler work ok for the ep93xx or should it
>  be "ep9312"?

Yes, arm920t is fine. Just pretend the maverick isn't there. :)
You only need ep9312 if you include maverick assembler fragments or
are using my fixed GCCs for Maverick
http://martinwguy.co.uk/martin/crunch
I got back to "no known bugs" in this stuff again three days ago, so
if you have FP-intensive stuff to run it might be worth trying.

   M

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[ng]

Martin Guy wrote:
> On 9/9/09, H Hartley Sweeten <hartleys@visionengravers.com> wrote:
>>  >> I used arm920t instead of ep9312 but I believe ep9312 is just an alias.
>>  > for arm920t, yes. It also passes "armv4t+maverick" to the assembler
>> So with "arm920t" does the assembler work ok for the ep93xx or should it
>>  be "ep9312"?
> 
> Yes, arm920t is fine. Just pretend the maverick isn't there. :)
> You only need ep9312 if you include maverick assembler fragments or
> are using my fixed GCCs for Maverick
> http://martinwguy.co.uk/martin/crunch
> I got back to "no known bugs" in this stuff again three days ago, so
> if you have FP-intensive stuff to run it might be worth trying.
> 
>    M


Thanks for that link , and all your efforts to knock some sensible ARM 
code out of GCC . Kudos.

I see you're posting patch sets for 4.2 and 4.3. I recall you said 
somewhere that 4.2.x produced faster ARM code. Is that still your 
experience?

best regards, Peter.



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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[wino]

ng@piments.com wrote:

> Thanks for that link , and all your efforts to knock some sensible ARM 
> code out of GCC . Kudos.
> 
> I see you're posting patch sets for 4.2 and 4.3. I recall you said 
> somewhere that 4.2.x produced faster ARM code. Is that still your 
> experience?
> 
> best regards, Peter.
> 

Sorry , this is fully covered in the link.

thx

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Martin Guy]

On 9/11/09, ng@piments.com <ng@piments.com> wrote:
>  I see you're posting patch sets for 4.2 and 4.3. I recall you said
> somewhere that 4.2.x produced faster ARM code. Is that still your
> experience?

THere's some extra measurements I didn't post there: using differen
GCCs to compile gcc-4.3.4, and measuring the size of the different
GCCs themselves and the size of the object code they generate and the
maximum memory they use to do it (compiling insn_recog.c as a rule):

        --the compiler itself-- --on gcc-4.3.2 stage1--
Version  gcc     cc1     cc1    Elapsed Max VM  xgcc
         text    text    data   time    used    text
gcc-3.4  79579  3862155   3236  4m30    104128  209509
gcc-4.0  86429  4579965  10208  4m44    111104  225846
gcc-4.1 193369  5115620  15976  4m56    123264  226469
gcc-4.2 188582  5490547  17364  4m50    112128  221171
gcc-4.3 203918* 7010746 420820  6m41    157440  227755
gcc-4.4 202989* 9431805 546128  8m21    170550  249260
llvm4.2 189365                  4m56     67136  236957

so 4.2 shows an unexpected dip in its own size, its memory use, the
time it takes to run and the size of its output code.
(Maybe it was just gathering its strength for the exponential growth
from 4.3 onwards :)

   M

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Khem Raj]

On (11/09/09 23:20), Martin Guy wrote:
> On 9/11/09, ng@piments.com <ng@piments.com> wrote:
> >  I see you're posting patch sets for 4.2 and 4.3. I recall you said
> > somewhere that 4.2.x produced faster ARM code. Is that still your
> > experience?
> 
> THere's some extra measurements I didn't post there: using differen
> GCCs to compile gcc-4.3.4, and measuring the size of the different
> GCCs themselves and the size of the object code they generate and the
> maximum memory they use to do it (compiling insn_recog.c as a rule):
> 
>         --the compiler itself-- --on gcc-4.3.2 stage1--
> Version  gcc     cc1     cc1    Elapsed Max VM  xgcc
>          text    text    data   time    used    text
> gcc-3.4  79579  3862155   3236  4m30    104128  209509
> gcc-4.0  86429  4579965  10208  4m44    111104  225846
> gcc-4.1 193369  5115620  15976  4m56    123264  226469
> gcc-4.2 188582  5490547  17364  4m50    112128  221171
> gcc-4.3 203918* 7010746 420820  6m41    157440  227755
> gcc-4.4 202989* 9431805 546128  8m21    170550  249260
> llvm4.2 189365                  4m56     67136  236957

Did you compile exact same insn_recog.c source ?
if not then you are comparing apples to pineapples.

-Khem
> 
> so 4.2 shows an unexpected dip in its own size, its memory use, the
> time it takes to run and the size of its output code.
> (Maybe it was just gathering its strength for the exponential growth
> from 4.3 onwards :)
> 
>    M
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Martin Guy]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On 9/12/09, Khem Raj <raj.khem@gmail.com> wrote:
> On (11/09/09 23:20), Martin Guy wrote:
>  >         --the compiler itself-- --on gcc-4.3.2 stage1--
>  > Version  gcc     cc1     cc1    Elapsed Max VM  xgcc
>  >          text    text    data   time    used    text
>  > gcc-3.4  79579  3862155   3236  4m30    104128  209509
>  > gcc-4.0  86429  4579965  10208  4m44    111104  225846
>  > gcc-4.1 193369  5115620  15976  4m56    123264  226469
>  > gcc-4.2 188582  5490547  17364  4m50    112128  221171
>  > gcc-4.3 203918* 7010746 420820  6m41    157440  227755
>  > gcc-4.4 202989* 9431805 546128  8m21    170550  249260
>  > llvm4.2 189365                  4m56     67136  236957
>
> Did you compile exact same insn_recog.c source ?

I built the same source tree gcc-4.3.2 (4.3.4 above was a typo) with
the same configuration line and CC=gcc-X.Y on x86.

What I've called "Max VM" here is obtained from the process accounting
records for the build run on an otherwise silent machine
It is the maximum value of the per-process "average VM usage", not the
high-water mark you see by watching "top" (216MB for 4.3). I can't
think of an easy way to measure the HWM.
You need a custom program to extract the top avg VM usage.
I used "lc" whose source is visible under
martinwguy.co.uk/martin/src/acct
lc | cut -c 52- | sed 's/ .*//' | sort -rn | head -1

    M

(BTW this is off topic for crossgcc any more)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: lc.c --]
[-- Type: text/x-csrc; name="lc.c", Size: 16412 bytes --]

/*
 *	lc - Visualizza gli ultimi commandi eseguiti
 *
 *	Per difetto, legge l'archivio ACCT_FILE. Se viene dato un parametro,
 *	legge quel file piuttosto.
 *
 *	Martin Guy, Catania, ottobre 2000
 *
 *	Modified dicembre 2002  x aggiungere -r (reverse-reverse-order flag)
 */

#include <stdio.h>
#include <stdlib.h> /* for exit() */

#ifdef linux
#include <linux/acct.h>	/* per struct acct etc. */
typedef struct acct_v3 acct_t;
#else
#include <sys/acct.h>	/* per struct acct etc. */
typedef struct acct acct_t;
#endif

#include <pwd.h>	/* per struct passwd, getpwuid() etc. */
#include <grp.h>	/* per convertire gid in nome gruppo */
#include <sys/time.h>	/* per select() */
#include <sys/types.h>	/* per dirent.h */
#include <dirent.h>	/* per opendir(), readdir() closedir() */
#include <sys/stat.h>	/* per lstat() */
#include <unistd.h>	/* per lstat() */
#include <time.h>	/* per struct tm etc */
#include <string.h>	/* per strchr() */
#include <sys/wait.h>	/* per decodificare exit status (macro W*()): richiede sys/types.h */

#include "comp_t.h"

/* Location of accounting file, which can be anywhere accoding to your distro.
 * Other favourite locations are /usr/adm/pacct /var/log/pacct and similar.
 */
#define ACCT_FILE "/var/log/account/pacct"

/* Alcuni parametri per la formattazione */
#define PWNAME_LEN	8	/* Stimata massima lunghezza del nome utente */
#define GRNAME_LEN	8	/* ditto nome gruppo */
#define TTYNAME_LEN	5	/* ditto nome tty (ttyS0, diciamo) */
#define TIME_LEN	4	/* ditto per CPU time e tempo trascorso */
/* N.B. anche print_ac_time() ipende del valore TIME_LEN per scegliere i vari
 * formati di stampa. Modificando TIME_LEN, bisogna anche modificare questa
 * funzione. */
#define DATE_LEN	16	/* Larghezza di data/ora prodotta da strftime */

static void usage(void);
static void do_backwards(FILE *acct_fp);
static void do_forwards(FILE *acct_fp);
static void do_follow(FILE *acct_fp);
static void print_ac_header(void);
static void print_ac(acct_t *a);
static void print_ac_time(comp_t atime, int int_width);
static void print_ac_date(time_t atime);
static void print_ac_tty(u_int16_t atty);
static void print_ac_exitcode(u_int32_t exitcode);

/* Se diversi di NULL, questi fanno vedere soltanto alcune record */
static char *sw_user = NULL;	/* per un'utente */
static char *sw_group = NULL;	/* per un gruppo */
static char *sw_tty = NULL;	/* su una tty */
static char *sw_cmd = NULL;	/* di un comando */

static int sw_follow = 0;	/* Fare come tail -f */
static int sw_forwards = 0;	/* Stampa nell'ordine in cui si trova nel file */

static u_int16_t sw_uid;	/* se sw_user != NULL, questo e` l'uid. */
static u_int16_t sw_gid;	/* se sw_group != NULL, questo e` il gid. */
static u_int16_t sw_ttydev;	/* se sw_tty != NULL, questo e` il major/minor del device. */

static char *argv0;	/* argv[0] for error reporting */

main(int argc, char **argv)
{
	char *acct_file = ACCT_FILE;
	FILE *acct_fp = NULL;

	argv0 = argv[0];

	/* Process switches (metodo all'antico...) */
	while (argc > 1 && argv[1][0] == '-') {
		char *arg;	/* seconda parte dei parametri di 2 arg */
		char sw;	/* ricorda carattere del flag */

		switch (sw = argv[1][1]) {
		case 'f':	/* Segui l'output mentre si aggiunge */
			sw_follow = 1;
			break;
		case 'r':	/* Stampa nell'ordeine del file */
			sw_forwards = 1;
			break;
		case 'u':	/* Stampa solo righe per utente X */
		case 'g':	/* Stampa solo righe per gruppo X */
		case 't':	/* Stampa solo righe per tty X */
		case 'c':	/* Stampa solo righe per comando X */
			if (argv[1][2] != '\0') arg = &(argv[1][2]);
			else if (argc < 3) usage();
			else {
				arg = argv[2];
				argv++; argc--;
			}
			switch (sw) {
			case 'u': sw_user = arg; break;
			case 'g': sw_group = arg; break;
			case 't': sw_tty = arg; break;
			case 'c': sw_cmd = arg; break;
			}
			break;
		case '\0':
			acct_file = "-";
			acct_fp = stdin;
			break;
		default:
			usage();
		}
		argv++; argc--;
	}

	/* Dovrebbe rimanere soltanto il nome facoltativo dell'archivio
	 * contabile */
	switch (argc) {
	case 1:
		break;
	case 2:
		if (acct_fp != NULL) {
			fputs("Specify one accounting file only.\n", stderr);
			exit(1);
		}
		acct_file = argv[1];
		break;
	default:
		usage();
		/* NOTREACHED */
	}

	/* Converte nome utente in uid ecc per filtraggio dei record */
	if (sw_user != NULL) {
		if (isdigit(sw_user[0])) sw_uid = atoi(sw_user);
		else {
			struct passwd *pw;
			pw = getpwnam(sw_user);
			if (pw == NULL) {
				fprintf(stderr, "%s: No such user \"%s\".\n",
					argv0, sw_user);
				exit(1);
			}
			sw_uid = pw->pw_uid;
		}
	}

	/* Converte nome gruppo in gid */
	if (sw_group != NULL) {
		if (isdigit(sw_group[0])) sw_gid = atoi(sw_group);
		else {
			struct group *gr;
			gr = getgrnam(sw_group);
			if (gr == NULL) {
				fprintf(stderr, "%s: No such group \"%s\".\n",
					argv0, sw_group);
				exit(1);
			}
			sw_gid = gr->gr_gid;
		}
	}

	/* Converte nome device in coppia major/minor */
	if (sw_tty != NULL) {
		int maj, min;
		/* Prima, controlla coppia esplicita maj/min */
		if (sscanf(sw_tty, "%d/%d", &maj, &min) == 2) {
			sw_ttydev = ((maj & 0xff) << 8) | (min & 0xff);
		} else {
			char devname[80]; /* speriamo che basti... */
			struct stat stbuf;

			sprintf(devname, "/dev/%s", sw_tty);
			if (stat(devname, &stbuf) != 0) {
				fprintf(stderr, "%s: Cannot stat ", argv0);
				perror(devname);
				exit(1);
			}
			sw_ttydev = stbuf.st_rdev;
		}
	}

	if (acct_fp == NULL) {
		acct_fp = fopen(acct_file, "r");
		if (acct_fp == NULL) {
			fputs("lc: Cannot read file ", stderr);
			perror(acct_file);
			exit(1);
		}
	}

	print_ac_header();

	if (sw_forwards) {
		do_forwards(acct_fp);
		if (sw_follow)
			/* forwards AND follow */
			/* We may miss a record or two if they were added
			 * between our EOF in do_forwards and our lseek()
			 * in do_follow().  Oh well...
			 */
			do_follow(acct_fp);
	} else {
		if (sw_follow) {
			do_follow(acct_fp);
		} else {
			do_backwards(acct_fp);
		}
	}

	exit(0);
}

static void
usage(void)
{
	fputs("Usage: lc [-f] [-u user] [-g group] [-t tty] [-c command] [acct_file]\n\
-f	Follow the accounting file: prints new records as they are added\n\
-u user	Only show records for a particular user (or numerical user-id)\n\
-g group Only show records for a group (or numerical group-id)\n\
-t tty	Only show records associated with a particular control terminal\n\
-c cmd	Only show records for a particular command\n\
Flags:\n\
F	Executed fork() but did not exec()\n\
S	used super-user privileges\n\
D	dumped core\n\
X	was killed by a signal\n\
Fields:\n\
USER	Real user name or user id\n\
TTY	Control terminal\n\
START	Process creation time\n\
USER	User CPU time\n\
SYS	System CPU time\n\
REAL	Elapsed time\n\
MEM	Average memory usage\n\
MIN	Minor page faults\n\
MAJ	Major page faults\n\
SW	Number of swaps\n\
EX	Exit code: if positive, this is the process' regular exit status;\n\
		   if negative, the untrapped signal that killed the process\n\
CMD	Command name\n", stderr);
	exit(1);
}

/*
 * Il solito modus operandi: Stampa i piu` recenti per primo, come "last".
 */
static void
do_backwards(FILE *acct_fp)
{
	acct_t a;

	if (fseek(acct_fp, (long) -sizeof(acct_t), SEEK_END) != 0) {
		perror("lc: Cannot seek to last record");
		exit(1);
	}

	while (fread(&a, sizeof(acct_t), 1, acct_fp) == 1) {
		print_ac(&a);

		/*
		 * Seek back over the record we just read and position at the
		 * start of the previous one. N.B. The manual doesn't say that
		 * we can do negative seeks, so we may have to change strategy
		 * to measure the size of the file at startup, then seek to
		 * explicit offsets.
		 */
		if (fseek(acct_fp, (long) (-sizeof(acct_t) * 2), SEEK_CUR) != 0) break;
	}
}

/*
 * l'insolito modus operandi: Stampa i piu` vecchi per primo.
 */
static void
do_forwards(FILE *acct_fp)
{
	acct_t a;

	rewind(acct_fp);	/* "cannot" fail */

	while (fread(&a, sizeof(acct_t), 1, acct_fp) == 1) {
		print_ac(&a);
	}
}

/*
 * Mostra i nuovi record mentre arivano, alla "tail -f".
 */
static void
do_follow(FILE *acct_fp)
{
	acct_t a;
	/* Roba per select() */
	fd_set rfds;
	int retval;

	FD_ZERO(&rfds);
	FD_SET(fileno(acct_fp), &rfds);

	/* Seek to end of accounting file.
	 * if sw_follow and sw_forwards are both true, do_follow() is
	 * called *after* sw_forwards, and the file pointer is already
	 * positioned at the next record we should print (or at EOF).
	 */
	if (!sw_forwards) {
		if (fseek(acct_fp, 0L, SEEK_END) != 0) {
			perror("lc: Cannot seek to last record");
			exit(1);
		}
	}

	for(;;) {
		while (fread(&a, sizeof(acct_t), 1, acct_fp) == 1) {
			print_ac(&a);
		}
		if (ferror(acct_fp)) {
			perror("Error reading accounting file");
			exit(1);
		}
#if 0
		if (select(fileno(acct_fp) + 1, &rfds, NULL, NULL, NULL) != 1) {
			perror("Error waiting for data");
			exit(1);
		}
#else
		/*
		 * select() is also "ready" on end-of-file, so is useless here,
 		 * and makes us loop taking 100% CPU!
		 */
		sleep (1);
#endif
	}
}

/* Stampa intestazione all'inizio della listata */
static void
print_ac_header(void)
{
	fputs("\
FLAG USER     TTY   START           USER SYS  REAL MEM  MIN MAJ SW EX CMD\
\n", stdout);
}

/* Decodifica e stampa un record contabile */
static void
print_ac(acct_t *a)
{
	struct passwd *pw;
	struct group *gr;

	/* Prima, controlla se dobbiamo excludere questo record */
	if (sw_user != NULL && a->ac_uid != sw_uid) return;
	if (sw_group != NULL && a->ac_gid != sw_gid) return;
	if (sw_tty != NULL && a->ac_tty != sw_ttydev) return;
	if (sw_cmd != NULL && strcmp(a->ac_comm, sw_cmd) != 0) return;

	/* Decodifica dei flag */
	printf("%c%c%c%c ",
		(a->ac_flag & AFORK)   ? 'F' : ' ',
		(a->ac_flag & ASU)     ? 'S' : ' ',
	/* printf("%c", (a->ac_flag & ACOMPAT) ? 'C' : ' '); Solo sul VAX */
		(a->ac_flag & ACORE)   ? 'D' : ' ',
		(a->ac_flag & AXSIG)   ? 'X' : ' ');

	/* Decodifica del nome dell'utente contabile */
	pw = getpwuid(a->ac_uid);
	if (pw != NULL) {
		/* Nome utente, allineato a sinistra */
		printf("%-*s ", PWNAME_LEN, pw->pw_name);
	} else {
		/* Conversione in nome utente fallito: stampa uid numerico
		 * allineato a sinistra */
		printf("%-*d ", PWNAME_LEN, a->ac_uid);
	}

#ifdef SHOW_GROUP
	/* E del gruppo contabile */
	gr = getgrgid(a->ac_uid);
	if (gr != NULL) {
		printf("%-*s ", GRNAME_LEN, gr->gr_name);
	} else {
		printf("%-*d ", GRNAME_LEN, a->ac_gid);
	}
#endif

	/* Stampa nome del Control Terminal */
	print_ac_tty(a->ac_tty);

	/* Start time in seconds since the epoch (as unsigned 32-bit int) */
	print_ac_date((time_t) a->ac_btime);

/*
  Campi utime fino a swaps sono di tipo comp_t.
  comp_t is a 16-bit "floating" point number with a 3-bit base 8
  exponent and a 13-bit fraction. See linux/kernel/acct.c for the
  specific encoding system used.
*/
	/* User and system CPU use, and elapsed times, presumably in AHZ. */
	print_ac_time(a->ac_utime, 1); fputs(" ", stdout);
	print_ac_time(a->ac_stime, 1); fputs(" ", stdout);
	print_ac_time(a->ac_etime, 2); fputs(" ", stdout);

	printf("%4ld ", decode_comp_t(a->ac_mem));
	/* printf("%d ", decode_comp_t(a->ac_io));	/* Sempre 0? */
	/* printf("%d ", decode_comp_t(a->ac_rw));	/* Sempre 0? */
	printf("%3ld ", decode_comp_t(a->ac_minflt));
	printf("%3ld ", decode_comp_t(a->ac_majflt));
	printf("%ld ", decode_comp_t(a->ac_swaps));
	print_ac_exitcode(a->ac_exitcode);
	printf("%s\n", a->ac_comm);
}

/* Stampa secondi di CPU o tempo reale in 4 caratteri.
 * fino a 10 secondi, stampiamo 1.24
 * da 10 secondi fino ad un minuto, stampiamo 13.4
 * da un minuto fino a dieci minuti, stampiano 3m42
 * da 10 minuti fino ad una ora, "45m"
 * da una ora fino a dieci ore, stampiano "3h24" (3 ore 24 minuti)
 * da 10 ore in poi, stampiamo "24h" ecc.
 *
 * Non facciamo arrotondamento.
 */
#define MINSEC 60
#define HOURSEC 3600
static void
print_ac_time(comp_t atime, int int_width)
{
	unsigned long time = decode_comp_t(atime);
	double ftime = (double)time / (double)AHZ;	/* tempo in secondi */

	/* Se int_width == 2, la formattazione viene regolare fino a 99.99
	 * secondi; da 100 in poi, spinge il resto della riga a destra.
	 * 5.2f: minimo di 5 caratteri: 2 frazionali, il punto e 3 di intero.
	 */
	if (ftime < 10.0)	/* meno di 10 secondi */
		printf("%*.2f", TIME_LEN, ftime);
	else if (ftime < 60.0)	/* 10 secondi fino a 59.9 secondi */
		printf("%*.1f", TIME_LEN, ftime);
	else if (ftime < 600.0) /* un minuto fino a 9:59 minuti */
		printf("%1dm%02d", (int)ftime / 60, (int)ftime % 60);
	else if (ftime < 3600.0) /* 10 minuti fino a 59m */
		printf("%2dm ", (int)ftime / 60);
	else if (ftime < 36000.0) /* 1 ora fino a 9h59 */
		/* Dipende da 32-bit int! */
		printf("%dh%02d", (int)ftime / 3600, ((int)ftime/60)%60);
	else  printf("%3dh", (int)((long) ftime / 3600));
}

/* Converte numero del Control Terminal in nome del device.
 * 0 sembra significare "nessuno", mentre altri numeri sono fatti dal
 * major_device_number * 256 + minor_device_number
 *
 * L'algoritmo attuale e` inefficiente: fa la scansione di /dev ogni volta
 * per ripescare, in tutta probabilita, gli stessi nomi.
 *
 * Nel caso dei pts, siamo fregati.  Anche se li andiamo a cercare in
 * /dev/pts/*, la presenza di una tale voce dipende dalla presenza attuale
 * dell'utente.  Controlliamo per questo caso specifico (ugh!)
 */
static void
print_ac_tty(u_int16_t atty)
{
	DIR *d = NULL;		/* Puntatore a /dev per leggere i nomi */
	struct dirent *dirent;	/* Puntatore all'elemento attuale in /dev */
	char *ttyname = NULL;	/* Nome del device in questione, se trovato */
	static char *ttyname_cache[65536]; /* Init to NULL */

	if (ttyname_cache[atty] != NULL) {
		ttyname = ttyname_cache[atty];
	} else {
		if (atty == 0) ttyname = "-";
		else if ((atty & 0xff00) == 136<<8) {
			/* Pseudo-terminal. Emmettiamo "pts/n" */
			static char ptsname[8];	/* 3 + 1 + 3 + '\0' */

			sprintf(ptsname, "pts/%d", atty & 0xff);
			ttyname = ptsname;
		} else {
			/* Cerca device in /dev */
			d = opendir("/dev");
			if (d == NULL) {
				perror("lc: Cannot read /dev");
				exit(1);
			}
			while ((dirent = readdir(d)) != NULL) {
				static char devname[5 + NAME_MAX + 1];
				struct stat stbuf;

				sprintf(devname, "/dev/%s", dirent->d_name);
				if (lstat(devname, &stbuf) != 0) {
					fputs("lc: Cannot stat ", stderr);
					perror(devname);
					continue;	/* Non e` fatale */
				}
				
				/* Cerca device a caratteri con major & minor giusti */
				if (S_ISCHR(stbuf.st_mode) && stbuf.st_rdev == atty) {
					ttyname = dirent->d_name;
					break;
				}
			}

			if (ttyname == NULL) {
				static char majmin[8];
				/* Non e` stato trovato una device che corrisponde
				 * Stampa major/minor. */
				sprintf(majmin, "%d/%d", (atty >> 8) & 0xff, atty & 0xff);
				ttyname = majmin;
			}
		}
		/* Ricorda questo nome nella cache */
		ttyname_cache[atty] = strdup(ttyname);
	}

	/* Stampa info *prima* di chiamare closedir() perché lo spazio in
	 * cui il nome e` registrato appartiene a opendir/readdir */
	printf("%-*s ", TTYNAME_LEN, ttyname);

	/* Se l'abbiamo aperto, lo chiudiamo */
	if (d != NULL) closedir(d);
}

/* Stampa ora d'inizio processo, convertendo da numero di secondi dall'epoch */
static void
print_ac_date(time_t atime)
{
	struct tm *tm;		/* Ora decomposta in campi separati */
	char strtime[DATE_LEN+1];	/* Ora pronta da stampare */
	char *s, *p;
	
	tm = localtime(&atime);
	s = asctime(tm);
	/* Hack brutale per togliere giorno-di-settimana iniziale e anno finale,
	 * tenendo uno spazio finale. */
	printf("%.16s", s+4);
}

/* Stampa campo "exitcode", codificato come il campo "status" pescato da
 * wait(2), e cioe` con il valore passato ad exit() negli otto bit superiori,
 * il signal che l'ha ucciso negli 7 bit inferiori, e con bit 128 settato se
 * il processo ha lasciato un core dump (quest'informazione presente anche nel
 * campo "flags" del struct acct).
 * Non so se e` necessario stampare sia exit code sia segnale che l'ha ucciso;
 * m'immagino che coltanto uno dei due puo` avere un valore diverso da zero.
 *
 * Per distinguere in breve, le uccisioni per exit stampano valori positivi
 * (di solito 0-127) e per i segnali, valori negativi (i segnali sono di solito
 * di valori di una o de cifre).
 */
static void
print_ac_exitcode(u_int32_t exitcode)
{
	/* Soltanto uno di questi due dovrebbe mai essere vero */
	if (WIFEXITED(exitcode)) printf("%3d ", WEXITSTATUS(exitcode));
	if (WIFSIGNALED(exitcode)) printf("%3d ", -WTERMSIG(exitcode));
}

[-- Attachment #3: comp_t.c --]
[-- Type: text/x-csrc, Size: 1687 bytes --]

/*
 * comp_t.c
 *
 * Routine per la manipolazione dei record di accounting di Linux.
 *
 * decode_comp_t() converte le quantita` codificate in comp_t
 *	nel semplice numero che codifica.
 *
 * Martin Guy, FreakNet Medialab, Luglio 2001
 */

#include "comp_t.h"

#if 0
/* Da /usr/src/linux/kernel/acct.c */
/*
 *  encode an unsigned long into a comp_t
 *
 *  This routine has been adopted from the encode_comp_t() function in
 *  the kern_acct.c file of the FreeBSD operating system. The encoding
 *  is a 13-bit fraction with a 3-bit (base 8) exponent.
 */

#define	MANTSIZE	13			/* 13 bit mantissa. */
#define	EXPSIZE		3			/* Base 8 (3 bit) exponent. */
#define	MAXFRACT	((1 << MANTSIZE) - 1)	/* Maximum fractional value. */

static comp_t encode_comp_t(unsigned long value)
{
	int exp, rnd;

	exp = rnd = 0;
	while (value > MAXFRACT) {
		rnd = value & (1 << (EXPSIZE - 1));	/* Round up? */
		value >>= EXPSIZE;	/* Base 8 exponent == 3 bit shift. */
		exp++;
	}

	/*
         * If we need to round up, do it (and handle overflow correctly).
         */
	if (rnd && (++value > MAXFRACT)) {
		value >>= EXPSIZE;
		exp++;
	}

	/*
         * Clean it up and polish it off.
         */
	exp <<= MANTSIZE;		/* Shift the exponent into place */
	exp += value;			/* and add on the mantissa. */
	return exp;
}
#endif

/* Convertita nella funzione inversa... */
#define	MANTSIZE	13			/* 13 bit mantissa. */
#define	EXPSIZE		3			/* Base 8 (3 bit) exponent. */

unsigned long
decode_comp_t(comp_t comp)
{
	unsigned long value;
	int exp;

	exp = comp >> MANTSIZE;		/* Sappiamo che comp_t e` unsigned */
	value = comp & ((1<<MANTSIZE) - 1);

	return(value << (exp * 3));	/* Exponent is in base 8 */
}

[-- Attachment #4: comp_t.h --]
[-- Type: text/x-chdr, Size: 163 bytes --]

/*
 * Declarations for clients of comp_t.c
 */

#ifdef linux
#include <linux/acct.h>
#else
#include <sys/acct.h>
#endif

unsigned long decode_comp_t(comp_t comp);

[-- Attachment #5: Makefile --]
[-- Type: application/octet-stream, Size: 480 bytes --]

CFLAGS=-O2

# All installable targets
PROGS=lc procacct weedacct

all: $(PROGS)

lc: lc.o comp_t.o
	cc $(CFLAGS) -o lc lc.o comp_t.o

install: $(PROGS)
	install -s -m 755 -o bin -g bin lc /usr/local/bin/
	install -m 644 -o root -g root lc.1 /usr/local/man/man1/
	install -m 644 -o root -g root lc.1.it /usr/local/man/it/man1/lc.1
	install -s -m 755 -o root -g root procacct /usr/local/sbin/
	install -s -m 755 -o root -g root weedacct /usr/local/sbin/

clean:
	rm -f *.o $(PROGS)

[-- Attachment #6: Type: text/plain, Size: 71 bytes --]

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Khem Raj]

2009/9/13 Martin Guy <martinwguy@gmail.com>:
> On 9/12/09, Khem Raj <raj.khem@gmail.com> wrote:
>> On (11/09/09 23:20), Martin Guy wrote:
>>  >         --the compiler itself-- --on gcc-4.3.2 stage1--
>>  > Version  gcc     cc1     cc1    Elapsed Max VM  xgcc
>>  >          text    text    data   time    used    text
>>  > gcc-3.4  79579  3862155   3236  4m30    104128  209509
>>  > gcc-4.0  86429  4579965  10208  4m44    111104  225846
>>  > gcc-4.1 193369  5115620  15976  4m56    123264  226469
>>  > gcc-4.2 188582  5490547  17364  4m50    112128  221171
>>  > gcc-4.3 203918* 7010746 420820  6m41    157440  227755
>>  > gcc-4.4 202989* 9431805 546128  8m21    170550  249260
>>  > llvm4.2 189365                  4m56     67136  236957
>>
>> Did you compile exact same insn_recog.c source ?
>
> I built the same source tree gcc-4.3.2 (4.3.4 above was a typo) with
> the same configuration line and CC=gcc-X.Y on x86.
>
> What I've called "Max VM" here is obtained from the process accounting
> records for the build run on an otherwise silent machine
> It is the maximum value of the per-process "average VM usage", not the
> high-water mark you see by watching "top" (216MB for 4.3). I can't
> think of an easy way to measure the HWM.
> You need a custom program to extract the top avg VM usage.
> I used "lc" whose source is visible under
> martinwguy.co.uk/martin/src/acct
> lc | cut -c 52- | sed 's/ .*//' | sort -rn | head -1

nice thanks for info
>
>    M
>
> (BTW this is off topic for crossgcc any more)
>

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

crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[H Hartley Sweeten]

Hello all,

I have been trying to get CodeSourcery's arm-none-linux-gnueabi (Sourcery
G++ Lite 2009q1-203) 4.3.3 toolchain to work with Buildroot and an EP93xx
based target.  Unfortunately Buildroot is not setup to handle the multilib
feature of that toolchain (default libraries are for ARMv5T).  I have
tried a number of ways in Buildroot to get that that toolchain to work but
my resulting filesystem always dies due to an unrecognized instruction.

Today I downloaded crosstool-ng to try and build a sysroot toolchain
specifically for the armv4t.  I think I have everything setup correctly
but the build always dies at:

bigguiness@etch:~/toolchain$ ct-ng build
[INFO ]  Performing some trivial sanity checks
[INFO ]  Build started 20090908.131159
[INFO ]  Building environment variables
[WARN ]  You did not specify the build system. That's OK, I can guess...
[INFO ]  =================================================================
[INFO ]  Retrieving needed toolchain components' tarballs
[ERROR]    Build failed in step 'Retrieving needed toolchain components' tarballs'
[ERROR]    Error happened in '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/functions' in function 'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/functions' at line # 502 in function 'CT_GetCVS'
[ERROR]          called from '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/build/libc/glibc.sh' at line # 44 in function 'do_libc_get'
[ERROR]          called from '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/crosstool-NG.sh' at line # 496 in function 'main'
[ERROR]    Look at '/home/bigguiness/x-tools/arm-unknown-linux-gnueabi/build.log' for more info on this error.
[ERROR]  (elapsed: 9:41.97)
[09:42] / make: *** [build] Error 1
bigguiness@etch:~/toolchain$ 

I followed the Download and usage instructions on the website:

bigguiness@etch:~/src$ hg clone http://ymorin.is-a-geek.org/hg/crosstool-ng
bigguiness@etch:~/src$ cd crosstool-ng
bigguiness@etch:~/src/crosstool-ng$ ./configure --prefix=/home/bigguiness
bigguiness@etch:~/src/crosstool-ng$ make
bigguiness@etch:~/src/crosstool-ng$ export PATH="${PATH}:/home/bigguiness/bin"
bigguiness@etch:~/src/crosstool-ng$ cd /home/bigguiness/toolchain
bigguiness@etch:~/toolchain$ ct-ng help
bigguiness@etch:~/toolchain$ ct-ng menuconfig
bigguiness@etch:~/toolchain$ ct-ng build

I think I have everything setup and configured correctly but I can't figure
out why the build is failing.  From the build.log it appears that linuxthreads
is getting checked out but when the build tries to mv it the files do not exist:

[ALL  ]    cvs checkout: Updating linuxthreads/linuxthreads_db
[DEBUG]    ==> Executing: 'mv linuxthreads glibc-linuxthreads-cvs-2.7'
[ALL  ]    mv: cannot stat `linuxthreads': No such file or directory
[ERROR]    Build failed in step 'Retrieving needed toolchain components' tarballs'

Do I have something configured incorrectly or am I doing something wrong?
Is there a "magic" combination of the Binutils/C compiler/C-library version
that must be used?

Thanks for any reply,
Hartley Sweeten

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Yann E. MORIN]

Hello H Hartley,
All,

On Tuesday 08 September 2009 22:42:24 H Hartley Sweeten wrote:
> I have been trying to get CodeSourcery's arm-none-linux-gnueabi (Sourcery
> G++ Lite 2009q1-203) 4.3.3 toolchain to work with Buildroot and an EP93xx
> based target.  Unfortunately Buildroot is not setup to handle the multilib
> feature of that toolchain (default libraries are for ARMv5T).  I have
> tried a number of ways in Buildroot to get that that toolchain to work but
> my resulting filesystem always dies due to an unrecognized instruction.

If we can trust the Linux kernel, then the EP93xx is an arm920t, which
is an armv4, not an armv5t. Which can explain why you have an illegal
instruction...

> I followed the Download and usage instructions on the website:
[--SNIP install steps--]

Correct. :-)

> I think I have everything setup and configured correctly but I can't figure
> out why the build is failing.  From the build.log it appears that linuxthreads
> is getting checked out but when the build tries to mv it the files do not exist:
> [ALL  ]    cvs checkout: Updating linuxthreads/linuxthreads_db
> [DEBUG]    ==> Executing: 'mv linuxthreads glibc-linuxthreads-cvs-2.7'
> [ALL  ]    mv: cannot stat `linuxthreads': No such file or directory
> [ERROR]    Build failed in step 'Retrieving needed toolchain components' tarballs'

I don't download everything every time, so it may well be that something
broke at some point. Care to send your .config, so I can try to reproduce?

> Do I have something configured incorrectly or am I doing something wrong?
> Is there a "magic" combination of the Binutils/C compiler/C-library version
> that must be used?

There's no armv4t sample in crosstool-NG.
But you could base your configuration on the arm-unknown-linux-uclibc
sample, and update the configuration to something like:
  Target options -->
    (armv4t) Architecture level
    ()  Generate code for the specific ABI
    (ep9312) Emit assembly for CPU
    (ep9312) Tune for CPU
    (maverick) Use specific FPU
    Floating point: ---> hardware (FPU)

NB: do not enable EABI, I think it requires at least armv5t, but I'm
    not sure. So stay on the safe side, and stick with OABI.

I give no guarantee, as I don't have the HW, but you should give it a
try. Also, java is currently broken, so you should disable it in the
"C compiler" sub-menu...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Matthias Kaehlcke]

El Tue, Sep 08, 2009 at 11:17:34PM +0200 Yann E. MORIN ha dit:

> Hello H Hartley,
> All,
> 
> On Tuesday 08 September 2009 22:42:24 H Hartley Sweeten wrote:
> > I have been trying to get CodeSourcery's arm-none-linux-gnueabi (Sourcery
> > G++ Lite 2009q1-203) 4.3.3 toolchain to work with Buildroot and an EP93xx
> > based target.  Unfortunately Buildroot is not setup to handle the multilib
> > feature of that toolchain (default libraries are for ARMv5T).  I have
> > tried a number of ways in Buildroot to get that that toolchain to work but
> > my resulting filesystem always dies due to an unrecognized instruction.
> 
> If we can trust the Linux kernel, then the EP93xx is an arm920t, which
> is an armv4, not an armv5t. Which can explain why you have an illegal
> instruction...
> 
> > I followed the Download and usage instructions on the website:
> [--SNIP install steps--]
> 
> Correct. :-)
> 
> > I think I have everything setup and configured correctly but I can't figure
> > out why the build is failing.  From the build.log it appears that linuxthreads
> > is getting checked out but when the build tries to mv it the files do not exist:
> > [ALL  ]    cvs checkout: Updating linuxthreads/linuxthreads_db
> > [DEBUG]    ==> Executing: 'mv linuxthreads glibc-linuxthreads-cvs-2.7'
> > [ALL  ]    mv: cannot stat `linuxthreads': No such file or directory
> > [ERROR]    Build failed in step 'Retrieving needed toolchain components' tarballs'
> 
> I don't download everything every time, so it may well be that something
> broke at some point. Care to send your .config, so I can try to reproduce?
> 
> > Do I have something configured incorrectly or am I doing something wrong?
> > Is there a "magic" combination of the Binutils/C compiler/C-library version
> > that must be used?
> 
> There's no armv4t sample in crosstool-NG.
> But you could base your configuration on the arm-unknown-linux-uclibc
> sample, and update the configuration to something like:
>   Target options -->
>     (armv4t) Architecture level
>     ()  Generate code for the specific ABI
>     (ep9312) Emit assembly for CPU
>     (ep9312) Tune for CPU
>     (maverick) Use specific FPU
>     Floating point: ---> hardware (FPU)
> 
> NB: do not enable EABI, I think it requires at least armv5t, but I'm
>     not sure. So stay on the safe side, and stick with OABI.

nope, i use EABI with arm4vt CPUs (ep93xx). some time i ran into the
same issue as hartley, and martin guy kindly provided a solution:

http://sourceware.org/ml/crossgcc/2008-05/msg00009.html

-- 
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona

    I am incapable of conceiving infinity, and yet I do not accept finity
                          (Simone de Beauvoir)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Steve Papacharalambous]

Hi Hartley,

Not sure if it's any help but ltib (http://www.ltib.org) works with
multilib toolchains (including CodeSourcery's), and there is a BSP for
the EP93xx.

As far as I know this particular BSP only has a generic arm uClibc
toolchain available for selection, but if you use the custom toolchain
facility you may be able to get the BSP to build using the CodeSourcery
toolchain,

Best regards,

Steve

On Tue, 2009-09-08 at 16:42 -0400, H Hartley Sweeten wrote:
> Hello all,
> 
> I have been trying to get CodeSourcery's arm-none-linux-gnueabi (Sourcery
> G++ Lite 2009q1-203) 4.3.3 toolchain to work with Buildroot and an EP93xx
> based target.  Unfortunately Buildroot is not setup to handle the multilib
> feature of that toolchain (default libraries are for ARMv5T).  I have
> tried a number of ways in Buildroot to get that that toolchain to work but
> my resulting filesystem always dies due to an unrecognized instruction.
> 
> Today I downloaded crosstool-ng to try and build a sysroot toolchain
> specifically for the armv4t.  I think I have everything setup correctly
> but the build always dies at:
> 
> bigguiness@etch:~/toolchain$ ct-ng build
> [INFO ]  Performing some trivial sanity checks
> [INFO ]  Build started 20090908.131159
> [INFO ]  Building environment variables
> [WARN ]  You did not specify the build system. That's OK, I can guess...
> [INFO ]  =================================================================
> [INFO ]  Retrieving needed toolchain components' tarballs
> [ERROR]    Build failed in step 'Retrieving needed toolchain components' tarballs'
> [ERROR]    Error happened in '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/functions' in function 'CT_DoExecLog' (line unknown, sorry)
> [ERROR]          called from '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/functions' at line # 502 in function 'CT_GetCVS'
> [ERROR]          called from '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/build/libc/glibc.sh' at line # 44 in function 'do_libc_get'
> [ERROR]          called from '/home/bigguiness/lib/ct-ng-hg_default@1523_6c2a6c04187e/scripts/crosstool-NG.sh' at line # 496 in function 'main'
> [ERROR]    Look at '/home/bigguiness/x-tools/arm-unknown-linux-gnueabi/build.log' for more info on this error.
> [ERROR]  (elapsed: 9:41.97)
> [09:42] / make: *** [build] Error 1
> bigguiness@etch:~/toolchain$ 
> 
> I followed the Download and usage instructions on the website:
> 
> bigguiness@etch:~/src$ hg clone http://ymorin.is-a-geek.org/hg/crosstool-ng
> bigguiness@etch:~/src$ cd crosstool-ng
> bigguiness@etch:~/src/crosstool-ng$ ./configure --prefix=/home/bigguiness
> bigguiness@etch:~/src/crosstool-ng$ make
> bigguiness@etch:~/src/crosstool-ng$ export PATH="${PATH}:/home/bigguiness/bin"
> bigguiness@etch:~/src/crosstool-ng$ cd /home/bigguiness/toolchain
> bigguiness@etch:~/toolchain$ ct-ng help
> bigguiness@etch:~/toolchain$ ct-ng menuconfig
> bigguiness@etch:~/toolchain$ ct-ng build
> 
> I think I have everything setup and configured correctly but I can't figure
> out why the build is failing.  From the build.log it appears that linuxthreads
> is getting checked out but when the build tries to mv it the files do not exist:
> 
> [ALL  ]    cvs checkout: Updating linuxthreads/linuxthreads_db
> [DEBUG]    ==> Executing: 'mv linuxthreads glibc-linuxthreads-cvs-2.7'
> [ALL  ]    mv: cannot stat `linuxthreads': No such file or directory
> [ERROR]    Build failed in step 'Retrieving needed toolchain components' tarballs'
> 
> Do I have something configured incorrectly or am I doing something wrong?
> Is there a "magic" combination of the Binutils/C compiler/C-library version
> that must be used?
> 
> Thanks for any reply,
> Hartley Sweeten
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 


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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Martin Guy]

On 9/9/09, Steve Papacharalambous <stevep@zee2.com> wrote:
>  Not sure if it's any help but ltib (http://www.ltib.org) works with
>  multilib toolchains (including CodeSourcery's), and there is a BSP for
>  the EP93xx.

Hmm. Interesting, but it's a bit worrying that without asking you it
silently tries to use your sudo settings to install new packages as
soon as you run it. What else does it silently do to your system as
root without asking you?

    M

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Steve Papacharalambous]

On Wed, 2009-09-09 at 12:21 +0100, Martin Guy wrote:
> On 9/9/09, Steve Papacharalambous <stevep@zee2.com> wrote:
> >  Not sure if it's any help but ltib (http://www.ltib.org) works with
> >  multilib toolchains (including CodeSourcery's), and there is a BSP for
> >  the EP93xx.
> 
> Hmm. Interesting, but it's a bit worrying that without asking you it
> silently tries to use your sudo settings to install new packages as
> soon as you run it. What else does it silently do to your system as
> root without asking you?
> 
>     M

Hi Martin,

This is really a question for the ltib mailing list, or perhaps the ltib
FAQ may help?  http://www.ltib.org/documentation-LtibFaq

I only suggested this as a possible alternative to solve Hartley's
problem using the CodeSourcery multilib toolchain and not get into a
discussion about the relative merits of builder tools,

Best regards,

Steve






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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[ng]

H Hartley Sweeten wrote:
> Hello all,
> 
> I have been trying to get CodeSourcery's arm-none-linux-gnueabi (Sourcery
> G++ Lite 2009q1-203) 4.3.3 toolchain to work with Buildroot and an EP93xx
> based target.  Unfortunately Buildroot is not setup to handle the multilib
> feature of that toolchain (default libraries are for ARMv5T).  I have
> tried a number of ways in Buildroot to get that that toolchain to work but
> my resulting filesystem always dies due to an unrecognized instruction.
> 
> Today I downloaded crosstool-ng to try and build a sysroot toolchain
> specifically for the armv4t.  I think I have everything setup correctly
> but the build always dies at:
> 

I have made an eabi toolchain for TS boards based on the Cyrus chip 
using a fairly recent ct-ng.

You could try this .config as a basis.

HTH.


CT_LOCAL_TARBALLS_DIR="${CT_TOP_DIR}/src"
CT_SAVE_TARBALLS=y
CT_WORK_DIR="${CT_TOP_DIR}/targets"
CT_PREFIX_DIR="${CT_TOP_DIR}/x-tools/${CT_TARGET}"
CT_INSTALL_DIR="${CT_PREFIX_DIR}"
CT_INSTALL_DIR_RO=y
CT_USE_MIRROR=y
CT_MIRROR_BASE_URL="http://ymorin.is-a-geek.org/mirrors/"
CT_CONNECT_TIMEOUT=10
CT_OVERIDE_CONFIG_GUESS_SUB=y
CT_PARALLEL_JOBS=1
CT_LOAD=0
CT_NICE=0
CT_USE_PIPES=y
CT_LOG_EXTRA=y
CT_LOG_LEVEL_MAX="EXTRA"
CT_LOG_PROGRESS_BAR=y
CT_LOG_TO_FILE=y
CT_LOG_FILE_COMPRESS=y
CT_ARCH="arm"
CT_ARCH_SUPPORT_ARCH=y
CT_ARCH_SUPPORT_CPU=y
CT_ARCH_SUPPORT_TUNE=y
CT_ARCH_SUPPORT_FPU=y
CT_ARCH_SUPPORTS_BOTH_ENDIAN=y
CT_ARCH_DEFAULT_LE=y
CT_ARCH_ARCH="armv4t"
CT_ARCH_CPU=""
CT_ARCH_TUNE=""
CT_ARCH_FPU=""
CT_ARCH_LE=y
CT_ARCH_FLOAT_SW=y
CT_TARGET_CFLAGS="-O2 -fomit-frame-pointer "
CT_TARGET_LDFLAGS=""
CT_ARCH_arm=y
CT_ARCH_ARM_EABI=y
CT_USE_SYSROOT=y
CT_SYSROOT_DIR_PREFIX=""
CT_SHARED_LIBS=y
CT_TARGET_VENDOR="unknown"
CT_TARGET_ALIAS_SED_EXPR=""
CT_TARGET_ALIAS=""
CT_CROSS=y
CT_TOOLCHAIN_TYPE="cross"
CT_BUILD=""
CT_BUILD_PREFIX=""
CT_BUILD_SUFFIX=""
CT_KERNEL="linux"
CT_KERNEL_VERSION="2.6.29.1"
CT_KERNEL_linux=y
CT_KERNEL_LINUX_INSTALL=y
CT_KERNEL_LINUX_INSTALL_CHECK=y
CT_KERNEL_V_2_6_29_1=y
CT_KERNEL_LINUX_VERBOSITY_0=y
CT_KERNEL_LINUX_VERBOSE_LEVEL=0
CT_GMP_MPFR=y
CT_GMP_MPFR_TARGET=y
CT_GMP_V_4_2_4=y
CT_GMP_VERSION="4.2.4"
CT_GMP_CHECK=y
CT_MPFR_V_2_4_1=y
CT_MPFR_VERSION="2.4.1"
CT_MPFR_CHECK=y
CT_BINUTILS_VERSION="2.19.1"
CT_BINUTILS_V_2_19_1=y
CT_BINUTILS_EXTRA_CONFIG=""
CT_BINUTILS_FOR_TARGET=y
CT_BINUTILS_FOR_TARGET_IBERTY=y
CT_BINUTILS_FOR_TARGET_BFD=y
CT_CC="gcc"
CT_CC_VERSION="4.3.2"
CT_CC_gcc=y
CT_CC_V_4_3_2=y
CT_CC_GCC_4_3_or_later=y
CT_CC_CXA_ATEXIT=y
CT_CC_SJLJ_EXCEPTIONS_DONT_USE=y
CT_CC_CORE_EXTRA_CONFIG=""
CT_CC_EXTRA_CONFIG=""
CT_CC_PKGVERSION="crosstool-NG-${CT_VERSION}"
CT_CC_BUGURL=""
CT_CC_SUPPORT_CXX=y
CT_CC_SUPPORT_FORTRAN=y
CT_CC_SUPPORT_JAVA=y
CT_CC_SUPPORT_ADA=y
CT_CC_SUPPORT_OBJC=y
CT_CC_SUPPORT_OBJCXX=y
CT_CC_LANG_CXX=y
CT_LIBC="glibc"
CT_LIBC_VERSION="2.9"
CT_LIBC_glibc=y
CT_LIBC_V_2_9=y
CT_LIBC_GLIBC_CVS=y
CT_LIBC_GLIBC_CVS_date="2009-03-29"
CT_LIBC_GLIBC_EXTRA_CONFIG=""
CT_LIBC_GLIBC_CONFIGPARMS=""
CT_LIBC_GLIBC_EXTRA_CFLAGS=""
CT_LIBC_EXTRA_CC_ARGS=""
CT_LIBC_GLIBC_USE_PORTS=y
CT_LIBC_ADDONS_LIST=""
CT_LIBC_GLIBC_KERNEL_VERSION_AS_HEADERS=y
CT_LIBC_GLIBC_MIN_KERNEL="2.6.29.1"
CT_LIBC_SUPPORT_NPTL=y
CT_LIBC_SUPPORT_LINUXTHREADS=y
CT_THREADS="nptl"
CT_THREADS_NPTL=y
CT_TOOL_libelf=y
CT_LIBELF_V_0_8_10=y
CT_LIBELF_VERSION="0.8.10"
CT_TOOL_sstrip=y
CT_SSTRIP_BUILDROOT=y
CT_SSTRIP_FROM="buildroot"
CT_DEBUG_dmalloc=y
CT_DMALLOC_V_5_5_2=y
CT_DMALLOC_VERSION="5.5.2"
CT_DEBUG_duma=y
CT_DUMA_A=y
CT_DUMA_SO=y
CT_DUMA_V_2_5_14=y
CT_DUMA_VERSION="2_5_14"
CT_DEBUG_gdb=y
CT_GDB_CROSS=y
CT_GDB_NATIVE=y
CT_GDB_NATIVE_USE_GMP_MPFR=y
CT_GDB_GDBSERVER=y
CT_GDB_GDBSERVER_STATIC=y
CT_GDB_V_6_8=y
CT_GDB_VERSION="6.8"
CT_NCURSES_V_5_7=y
CT_NCURSES_VERSION="5.7"
CT_DEBUG_ltrace=y
CT_LTRACE_V_0_5=y
CT_LTRACE_VERSION="0.5"
CT_DEBUG_strace=y
CT_STRACE_V_4_5_17=y
CT_STRACE_VERSION="4.5.17"

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

RE: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[H Hartley Sweeten]

On Wednesday, September 09, 2009 6:40 AM, ng@piments.com wrote:
> H Hartley Sweeten wrote:
>> Hello all,
>> 
>> I have been trying to get CodeSourcery's arm-none-linux-gnueabi (Sourcery
>> G++ Lite 2009q1-203) 4.3.3 toolchain to work with Buildroot and an EP93xx
>> based target.  Unfortunately Buildroot is not setup to handle the multilib
>> feature of that toolchain (default libraries are for ARMv5T).  I have
>> tried a number of ways in Buildroot to get that that toolchain to work but
>> my resulting filesystem always dies due to an unrecognized instruction.
>> 
>> Today I downloaded crosstool-ng to try and build a sysroot toolchain
>> specifically for the armv4t.  I think I have everything setup correctly
>> but the build always dies at:
>> 
>
> I have made an eabi toolchain for TS boards based on the Cyrus chip 
> using a fairly recent ct-ng.
>
> You could try this .config as a basis.
>
> HTH.

My .config was very similar.  The only real difference is:

CT_THREADS="nptl"
CT_THREADS_NPTL=y

I had:

CT_THREADS="linuxthreads"
CT_THREADS_LINUXTHREADS=y

I'm trying the build now using nptl instead of linuxthreads.  So far it looks
good.  It appears something is wrong with the linuxthreads support.

Regards,
Hartley

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

Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)

[Martin Guy]

On 9/9/09, H Hartley Sweeten <hartleys@visionengravers.com> wrote:
>  CT_THREADS="nptl"
>  CT_THREADS_NPTL=y
>
> I had:
>
>  CT_THREADS="linuxthreads"
>  CT_THREADS_LINUXTHREADS=y
>
>  I'm trying the build now using nptl instead of linuxthreads.  So far it looks
>  good.  It appears something is wrong with the linuxthreads support.

Yes, EABI wants nptl, at least that's the only thread model I remember
working in 2006.  Maybe this knowledge could be taught to ct-ng?

    M

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