| Author |
Message |
|
|
Posted: Aug 06, 2006 - 06:51 AM |
|


Joined: Sep 14, 2003
Posts: 4209
Location: Queanbeyan, Australia
|
|
Hi All,
I'm going through and compiling the AVR32-linux toolchain on my linux box here at home. There have been a few things not mentioned on the avr32linux website which prevented compilation straight off the bat but most of them I've worked out. This latest one has me stumped though. During compilation of the uClibc, the libc/string/avr32/memset.s file spits out the error that insert.b and insert.h aren't valid ASM instructions. Well, indeed they are not but there they are. The lines from the .patch available from the avr32linux website that insert this erroneous code are
Code:
+.Llarge_memset:
+ mov r8, r11
+ mov r11, 3
+ insert.b r8:l, r8
+ tst s, r11
+ insert.h r8:t, r8
+ breq 2f
+
Can anyone tell me what these lines are doing here and how to get them to compile cleanly?
Cheers all,
S. |
|
|
| |
|
|
|
|
|
Posted: Aug 06, 2006 - 06:58 AM |
|


Joined: Sep 14, 2003
Posts: 4209
Location: Queanbeyan, Australia
|
|
further inspection and most of the .s files in that directory contain the insert and extract instructions that kill the compilation. There is a list of broken files in the Makefile and adding the offending asm files to this list at least means compilation can complete. Nevertheless, is this just an incomplete port or is there some other reason these not-really-instructions are all through that code?
Cheers again,
S. |
|
|
| |
|
|
|
|
|
Posted: Aug 06, 2006 - 09:43 AM |
|

Joined: Jan 20, 2003
Posts: 377
Location: Birmingham, England
|
|
looks like someone created a macro in the assembler but forgot to add the definition of it....maybe it is there somewhere but not shown to the files. Have you done a search for insert.b in the directory and see if the definition exists anyway. Or maybe it has just been left out.
Just thoughts, hope they help. |
|
|
| |
|
|
|
|
|
Posted: Aug 06, 2006 - 12:29 PM |
|


Joined: Apr 26, 2006
Posts: 1076
Location: Trondheim, Norway
|
|
Crap, that code is old...insert.b and friends were removed from the instruction set quite some time ago.
Try disabling "arch-specific string optimizations" (or something along those lines). The generic optimized version is actually pretty good.
Could you please list the things you had to to get as far as you did? There are probably other people who have/will run into the same problems. |
|
|
| |
|
|
|
|
|
Posted: Aug 07, 2006 - 07:13 AM |
|


Joined: Jan 07, 2003
Posts: 3753
Location: Trondheim, Norway
|
|
|
how wrote:
Crap, that code is old...insert.b and friends were removed from the instruction set quite some time ago.
Try disabling "arch-specific string optimizations" (or something along those lines). The generic optimized version is actually pretty good.
Could you please list the things you had to to get as far as you did? There are probably other people who have/will run into the same problems.
Disabling arch-specific string optimization in the string part of the C library corrects this problem. So it should be a) removed if AVR32 platform is selected or b) reimplemented using AVR32 valid assembler  |
|
|
| |
|
|
|
|
|
Posted: Aug 07, 2006 - 09:26 AM |
|


Joined: Apr 26, 2006
Posts: 1076
Location: Trondheim, Norway
|
|
|
|
|
|
|
Posted: Aug 07, 2006 - 09:29 AM |
|


Joined: Jan 07, 2003
Posts: 3753
Location: Trondheim, Norway
|
|
cd uClibc-0.9.28\test\string && make ? I'm not in an operating system right now, but I'll give it a go later today. |
|
|
| |
|
|
|
|
|
Posted: Aug 07, 2006 - 09:41 AM |
|


Joined: Apr 26, 2006
Posts: 1076
Location: Trondheim, Norway
|
|
Wow, right under my nose. Anyway,
~ # ./string
No errors.
Looking a bit closer, it doesn't seem like it's actually _using_ those optimized routines. I'll see if I can figure out why. |
|
|
| |
|
|
|
|
|
Posted: Aug 07, 2006 - 10:23 AM |
|


Joined: Apr 26, 2006
Posts: 1076
Location: Trondheim, Norway
|
|
These two patches should make uClibc use the arch-optimized routines when available:
http://avr32linux.org/twiki/pub/Main/Mi ... ixes.patch
http://avr32linux.org/twiki/pub/Main/Mi ... ones.patch
I'm a bit puzzled about the second change, though, as it implies that uClibc has never really used either the arch-optimized versions or the generic optimized versions. So that patch might actually give a quite significant speedup no matter whether you turn on the arch-specific stringops or not.
Must have been changed in 0.9.28 or something, as I'm certain I've compared the various implementations against each other at some point in the past. |
|
|
| |
|
|
|
|
|
Posted: Aug 07, 2006 - 12:28 PM |
|


Joined: Apr 26, 2006
Posts: 1076
Location: Trondheim, Norway
|
|
|
|
|
|
|
Posted: Aug 08, 2006 - 07:29 AM |
|


Joined: Sep 14, 2003
Posts: 4209
Location: Queanbeyan, Australia
|
|
Cheers how, thanks very much! For others with issues:
I followed the Getting Started on the avr32linux website, what I list below are just the bits that are different from what is said there.
Binutils worked fine once I downloaded the latest versions, for some reason the ones that shipped on my BSP CD was broked.
Next, the bootstrap GCC. The --disable-libmudflap option has to be specified when running ./configure along with with --disable-threads and --enable-languages=c . I have changed this on the avr32linux wiki already. Also note that you must create a folder for the GCC to be compiled in to. For example, on my system I extracted the gcc sources to ~/avr32dev/gcc-4.0.2 and then created a folder ~/avr32dev/gcc. From within this ~/avr32dev/gcc folder you must run ../gcc-4.0.2/configure [options] which then creates the makefile in the ~/avr32dev/gcc folder. A call to make from within the gcc folder will fetch the sources out of /avr32dev/gcc-4.0.2 and place the compiled binaries in /avr32dev/gcc. Simply running ./configure in the gcc-4.0.2 folder will throw up in-place compilation errors.
Preparing kernel headers: Make the changes in the root Makefile if you want but I don't think you actually need to make headers (my Makefile didn't even have that target in it). They seem to be there ready to use.
uClibc. By hacking bits out I got it to compile but now how has done the extra patches, nobody should have a problem. Thanks again how! One interesting thing is that you may need to run 'make defconfig' before 'make menuconfig' as, paradoxically, the defaults don't seem to be set by default :S. Of course, it could just be me being an idiot. Also in the menuconfig, set the include directory to the root of your linux source tree, the script automatically adds the /include. eg, if the sources are in ***/linux-2.6.11/include then just type ***/linux-2.6.11/
Bootloader compiled without an issue once I had the correct version (another example of me being stupid) as did the kernel. If you're having kernel issues, run 'make defconfig' and try compiling again to test whether its a fundamental issue or whether it's just your options not working.
Finally building the full gcc. I haven't sucessfully completed this step yet as I don't think I have correctly installed the uClibc. I will try again tonight and let everyone know my results. In the mean time, does anyone have any insight in to the installation of the uClibc? No instructions are included on the avr32linux website.
Please correct anything in this process that is wrong, I'm no expert and I'm sure some of the stuff I've done just to get it to work could be done better some other way.
Cheers all,
S. |
|
|
| |
|
|
|
|
|
Posted: Aug 10, 2006 - 12:51 PM |
|


Joined: Sep 14, 2003
Posts: 4209
Location: Queanbeyan, Australia
|
|
Well, some problems fixed. uClibc had installed itself to /usr/avr32-linux-uclibc but the gcc was looking for it in /usr/avr32-linux. All fixed now. Next problem:
Code:
checking for main in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make: *** [configure-target-libstdc++-v3] error 1
Any ideas? As seems obvious, this problem goes away and everything compiles cleanly so long as I leave c++ off the list of supported languages. Incidentally, the AVR32 patches for the GCC appear to apply cleanly to 4.0.3 as well as 4.0.2, though the problem persists.
Thanking all in advance,
S. |
|
|
| |
|
|
|
|
|
Posted: Aug 10, 2006 - 01:24 PM |
|


Joined: Jan 07, 2003
Posts: 3753
Location: Trondheim, Norway
|
|
I had to patch my C++ repository to get it to work well with uClibc.
Code:
diff -upr gcc-4.0.2/gcc/cp/cp-gimplify.c gcc-4.0.2-targetcompiler/gcc/cp/cp-gimplify.c
--- gcc-4.0.2/gcc/cp/cp-gimplify.c 2004-12-22 19:00:38.000000000 +0100
+++ gcc-4.0.2-targetcompiler/gcc/cp/cp-gimplify.c 2006-07-26 15:29:06.000000000 +0200
@@ -283,7 +283,10 @@ cp_genericize_r (tree *stmt_p, int *walk
tree stmt = *stmt_p;
struct pointer_set_t *p_set = (struct pointer_set_t*) data;
- if (is_invisiref_parm (stmt))
+ if (is_invisiref_parm (stmt)
+ /* Don't dereference parms in a thunk, pass the references through. */
+ && !(DECL_THUNK_P (current_function_decl)
+ && TREE_CODE (stmt) == PARM_DECL))
{
*stmt_p = convert_from_reference (stmt);
*walk_subtrees = 0;
diff -upr gcc-4.0.2/gcc/cp/method.c gcc-4.0.2-targetcompiler/gcc/cp/method.c
--- gcc-4.0.2/gcc/cp/method.c 2005-07-12 13:27:32.000000000 +0200
+++ gcc-4.0.2-targetcompiler/gcc/cp/method.c 2006-07-26 15:29:08.000000000 +0200
@@ -491,7 +491,8 @@ use_thunk (tree thunk_fndecl, bool emit_
t = build3 (COND_EXPR, TREE_TYPE (t), cond, t,
cp_convert (TREE_TYPE (t), integer_zero_node));
}
- t = force_target_expr (TREE_TYPE (t), t);
+ if (IS_AGGR_TYPE (TREE_TYPE (t)))
+ t = build_cplus_new (TREE_TYPE (t), t);
finish_return_stmt (t);
}
diff -upr gcc-4.0.2/gcc/tree.h gcc-4.0.2-targetcompiler/gcc/tree.h
--- gcc-4.0.2/gcc/tree.h 2005-08-23 09:39:41.000000000 +0200
+++ gcc-4.0.2-targetcompiler/gcc/tree.h 2006-07-26 15:39:56.000000000 +0200
@@ -1001,7 +1001,7 @@ extern void tree_operand_check_failed (i
/* In a CALL_EXPR, means that the call is the jump from a thunk to the
thunked-to function. */
-#define CALL_FROM_THUNK_P(NODE) ((NODE)->common.protected_flag)
+#define CALL_FROM_THUNK_P(NODE) (CALL_EXPR_CHECK (NODE)->common.protected_flag)
/* In a type, nonzero means that all objects of the type are guaranteed by the
language or front-end to be properly aligned, so we can indicate that a MEM
diff -upr gcc-4.0.2/libstdc++-v3/config/locale/generic/c_locale.h gcc-4.0.2-targetcompiler/libstdc++-v3/config/locale/generic/c_locale.h
--- gcc-4.0.2/libstdc++-v3/config/locale/generic/c_locale.h 2005-01-30 15:09:58.000000000 +0100
+++ gcc-4.0.2-targetcompiler/libstdc++-v3/config/locale/generic/c_locale.h 2006-07-26 14:55:30.000000000 +0200
@@ -41,12 +41,18 @@
#include <clocale>
#include <cstring> // get std::strlen
#include <cstdio> // get std::snprintf or std::sprintf
+#include <features.h>
+#include <ctype.h>
#define _GLIBCXX_NUM_CATEGORIES 0
namespace std
{
- typedef int* __c_locale;
+#ifdef __UCLIBC__
+ typedef __ctype_touplow_t* __c_locale;
+#else
+ typedef int* __c_locale;
+#endif
// Convert numeric value of type _Tv to string and return length of
// string. If snprintf is available use it, otherwise fall back to
diff -upr gcc-4.0.2/libstdc++-v3/config/os/gnu-linux/ctype_base.h gcc-4.0.2-targetcompiler/libstdc++-v3/config/os/gnu-linux/ctype_base.h
--- gcc-4.0.2/libstdc++-v3/config/os/gnu-linux/ctype_base.h 2004-11-23 10:18:38.000000000 +0100
+++ gcc-4.0.2-targetcompiler/libstdc++-v3/config/os/gnu-linux/ctype_base.h 2006-07-26 14:56:20.000000000 +0200
@@ -31,6 +31,8 @@
//
// ISO C++ 14882: 22.1 Locales
//
+#include <features.h>
+#include <ctype.h>
/** @file ctype_base.h
* This is an internal header file, included by other library headers.
@@ -43,7 +45,11 @@
struct ctype_base
{
// Non-standard typedefs.
- typedef const int* __to_type;
+#ifdef __UCLIBC__
+ typedef const __ctype_touplow_t* __to_type;
+#else
+ typedef const int* __to_type;
+#endif
// NB: Offsets into ctype<char>::_M_table force a particular size
// on the mask type. Because of this, we don't use an enum.
PS! This is fixed upstream in version 4.1 and "4.2", my fix above is a dirty quick fix.
PPS! Argh, seems like the code-tag is broken, I can email you the patch, just send me a PM with your address. |
|
|
| |
|
|
|
|
|
Posted: Aug 13, 2006 - 12:41 AM |
|


Joined: Sep 14, 2003
Posts: 4209
Location: Queanbeyan, Australia
|
|
Cheers hce, but no luck. Rather than try and debug the 100,000 line libstdc++ configuration script which was throwing up the error, for now, I just appended libstdc++-v3 to the avr32 $noconfigdirs in the top level configure.in. The same problem then popped up in the libgfortran compilation but since I didn't really need fortran anyway, I just configured the gcc not to compile it. The upshot is that the gcc has finally compiled but without libstdc++. If anyone wants an eye-over the libstdc++ or libgfortran config.log files, give us a pm.
Thanks all,
S.
ps. Is there anywhere where we should be posting bug reports like the above? Should we just do it in the main gcc bugtracker (probably not since 4.0.2 is an old version anyway) or is there somewhere special? |
|
|
| |
|
|
|
|
|
Posted: Aug 14, 2006 - 07:21 AM |
|


Joined: Jan 07, 2003
Posts: 3753
Location: Trondheim, Norway
|
|
We do not have any bugzilla for GCC, binutils, uClibc etc.
I am able to compile and use the C++ stuff, so I wonder why you are not able to compile it. Included is my configure line:
Code:
../configure --target=avr32-linux --build=i686-pc-linux-gnu --prefix=/usr --with-sysroot=/tftpboot/ap7000 --enable-uclibc --enable-languages=c,c++
The /tftpboot/ap7000 directory is a link to the nfs root for my ap7000 device, similar to /usr/avr32-linux. |
|
|
| |
|
|
|
|
|
Posted: Aug 21, 2006 - 09:25 PM |
|

Joined: Jul 10, 2006
Posts: 24
|
|
wow... I just saw a 3.2x performance improvement on memcpy using those new patches.  |
|
|
| |
|
|
|
|
|
Posted: Aug 22, 2006 - 07:20 AM |
|


Joined: Sep 14, 2003
Posts: 4209
Location: Queanbeyan, Australia
|
|
| OK, sorry for the delay all. The problem was a dumb one of course. It looks like at some stage I forgot to specify the correct target during the configure. Somewhere, some file was telling some part of the GCC it was being compiled for x86. This file was not cleaned by a make *clean, I assume because it is an x86-only bit and therefore wasn't touched by anything, not even clean, once all was configured for avr32. So, a full deletion of everything gcc-sourcy, reinflate, repatch, reconfigure, now all good. Thanks very much to everyone for their help on this and happy programming! |
|
|
| |
|
|
|
|
|
Posted: Sep 22, 2006 - 01:32 PM |
|

Joined: Sep 04, 2006
Posts: 41
Location: Trondheim, Norway
|
|
Hi all,
I have just installed vmplayer and are running a Fedora image. It is a clean image, with no extra features. I'm having trouble with the toolchain compilation. After downloading and pathcing the binutils, I run the following commands:
Code:
./configure --target=avr32-linux
No trouble here. Then I run make. The following error appears:
Code:
checking whether strstr must be declared... no
checking whether malloc must be declared... no
checking whether realloc must be declared... no
checking whether free must be declared... no
checking whether getenv must be declared... no
configure: error: *** unknown target vector bfd_elf32_avr32_vec
make: *** [configure-bfd] Error 1
Are there any libraries that I am missing? I have even tried to install all the rpm's first from the BSP that came with the AVR32, but that did not help. Anyone? |
|
|
| |
|
|
|
|
|
Posted: Sep 22, 2006 - 02:37 PM |
|

Joined: Aug 28, 2006
Posts: 11
|
|
| Did you do all the other steps (autoconf, automake etc.) explained on avr32linux.org after applying the patch? |
|
|
| |
|
|
|
|
|
Posted: Sep 22, 2006 - 02:46 PM |
|

Joined: Sep 04, 2006
Posts: 41
Location: Trondheim, Norway
|
|
Well, no. I have not tried that because the same page also tells me the following:
"If you download the pre-patched source, this has already been done for you."
Do I need to run autoconf etc even if I download the pre-patched source? If so, avr32linux should update this information. Or, I should read __even more__ carefully.  |
|
|
| |
|
|
|
|
|