|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
|
|
crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)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)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)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)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)> > (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)On 9/9/09, Steve Papacharalambous <stevep@...> 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)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)On Wed, 2009-09-09 at 12:21 +0100, Martin Guy wrote:
> On 9/9/09, Steve Papacharalambous <stevep@...> 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)On Wednesday, September 09, 2009 6:40 AM, ng@... 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)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)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. > 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)On 9/9/09, H Hartley Sweeten <hartleys@...> 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 |
|
|
Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)On 9/9/09, H Hartley Sweeten <hartleys@...> 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)Martin Guy wrote:
> On 9/9/09, H Hartley Sweeten <hartleys@...> 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)ng@... 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)On 9/11/09, ng@... <ng@...> 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)On (11/09/09 23:20), Martin Guy wrote:
> On 9/11/09, ng@... <ng@...> 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)On 9/12/09, Khem Raj <raj.khem@...> 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 ? 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) [lc.c] /* * 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)); } [comp_t.c] /* * 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 */ } [comp_t.h] /* * 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); -- For unsubscribe information see http://sourceware.org/lists.html#faq |
|
|
Re: crosstool-ng: cross compiler for -mach=arm4vt (Cirrus Logic EP93xx target)2009/9/13 Martin Guy <martinwguy@...>:
> On 9/12/09, Khem Raj <raj.khem@...> 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 |
| Free embeddable forum powered by Nabble | Forum Help |