This is the mail archive of the mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BFD does not support target avr32-unknown-none.

On 02/20/11 10:04, wrote:
On 02/18/11 13:02, Per Arnold Blaasmo wrote:
On 18. feb. 2011 11:40, wrote:

On 02/18/11 10:11, Per Arnold Blaasmo wrote:
On 18. feb. 2011 02:37, wrote:
On 02/17/11 17:41, wrote:
On 02/15/11 16:07, Per Arnold Blåsmo wrote:
Have a look at
for some patches.

Following Yann's request in an adjacent thread , the attached tarball is my reworking of the above linked patches for binutils into a unified form acceptable to ct-ng automatic processing.

They are hopefully identical in effect on the code. All changes are only to account for different applications of diff options in various files.

Regards Per A.

On 15. feb. 2011 13:31, wrote:
On 15/02/11 00:07, Yann E. MORIN wrote:
Peter, All,

On Monday 14 February 2011 23:39:19 wrote:
I am attempting to use ct-ng to build a toolchain for avr32.

I used the 'sample' included in 1.9.2 and it built OK. But when I
try to
add gdb it fails with an obscure error I have not been able to
info on.

nano /back/ts/ct-ng/x-tools/avr32-unknown-none/build.log
[ALL ] checking linker --as-needed support... yes
[ALL ] checking for cos in -lm... yes
[ALL ] *** BFD does not support target avr32-unknown-none.
[ALL ] *** Look in bfd/config.bfd for supported targets.

It seems to me that avr32 is not supported in upstream gdb. It requires a patch, which you may get from Atmel (registration required):

Look for:

AVR32 GNU Toolchain 2.4.2 - Linux Source Code (102 MB, revision
2.4.2, updated 01/10) AVR32 GNU Toolchain Linux Source code

I don't know what version of gdb is available in there, though.
I am
not registered.

Going the hacker's way, would it be possible to replace the gdb
the one from binutils? Hehe... Open-heart surgery. :-]

Maybe not so hairy.

from avr32-gdb.spec :

# Remove the files that are part of a gdb build but that are owned
# provided by other packages.
# These are part of binutils

%__rm -rf $RPM_BUILD_ROOT/usr/share/locale/
%__rm -f $RPM_BUILD_ROOT%{_infodir}/bfd*
%__rm -f $RPM_BUILD_ROOT%{_infodir}/standard*
%__rm -f $RPM_BUILD_ROOT%{_infodir}/mmalloc*
%__rm -f $RPM_BUILD_ROOT%{_infodir}/configure*
%__rm -rf $RPM_BUILD_ROOT/usr/include/
%__rm -rf

If my, as yet limited understanding of this process is correct, it seems that they are using the binutils bfd.

Make sense?

regards, Peter.

I know this build is marked experimental but I see a lot of
stuff out
there that seems to suggest avr-gdb is working on linux

Warning: avr != avr32. avr is 8-bit, avr32 is 32-bit. What you want is avr32-gdb.

Yann E. MORIN.

Thanks Per, it looks like that is more upto date than what I was
from the other download.


I added usual structures at the same level as the stock ct-ng patch
directory and added the patches . ct-ng build started well and
patches all applied cleanly , but then it got confused in gcc-4.3.3.

diff -rupwN gcc/calls.c gcc/calls.c --- gcc/calls.c 2008-06-24 02:58:17.000000000 -0500 +++ gcc/calls.c 2010-08-26 11:56:14.000000000 -0500 @@ -3466,7 +3466,7 @@ emit_library_call_value_1 (int retval, r for (; count< nargs; count++) { rtx val = va_arg (p, rtx); - enum machine_mode mode = va_arg (p, enum machine_mode); + enum machine_mode mode = va_arg (p, int);

/* We cannot convert the arg value to the mode the library wants
must do it earlier where we know the signedness of the arg. */
diff -rupwN gcc/config/avr32/avr32.c gcc/config/avr32/avr32.c
--- gcc/config/avr32/avr32.c 1969-12-31 18:00:00.000000000 -0600
+++ gcc/config/avr32/avr32.c 2010-08-26 11:59:24.000000000 -0500
@@ -0,0 +1,8090 @@

The latter snip "worked" because it created a new file (althought it created it at the wrong level) , all other parts of the patch, like the first snip here, failed to find the targer file.

here's the first binutls patch that did work:

diff -Nwarup ./config/override.m4
--- ./config/override.m4 2010-03-03 19:28:57.000000000 +0530
+++ ../avr32-binutils-trunk/config/override.m4 2010-04-01
19:28:34.968750000 +0530
@@ -52,7 +52,7 @@ dnl Or for updating the whole tree at on
m4_defn([m4_PACKAGE_VERSION]), [],
- [m4_fatal([Please use exactly Autoconf ]_GCC_AUTOCONF_VERSION[
of ]m4_defn([m4_PACKAGE_VERSION])[.])])
+ [m4_errprintn([Please use exactly Autoconf ]_GCC_AUTOCONF_VERSION[
instead of ]m4_defn([m4_PACKAGE_VERSION])[.])])
m4_define([AC_INIT], m4_defn([AC_INIT])[

comparing the formats it seems like they were not created in the same

if I add ./ to all file names and add -a to diff it works:

diff -rupwNa ./gcc/calls.c ./gcc/calls.c
--- ./gcc/calls.c 2008-06-24 02:58:17.000000000 -0500
+++ ./gcc/calls.c 2010-08-26 11:56:14.000000000 -0500

I guess this was some kind of error in preparation of those patches but it's a headache.

Can anyone suggest a simple means to correct this ? I presume ct-ng
is a
bit stubborn about what format it expects so I'm looking for an
alternative to hand editing every line of each hunk.

There's a lot of files with lots of hunks.

Is there an obvious trick I'm missing?


For unsubscribe information see

OK, after much grepping and sedding I have got all those patches into some kind of consistent state that ct-ng can deal with in one go.

However, binutls fails during configure.:

[ALL ] checking for zlib.h... yes
[ALL ] checking linker --as-needed support... yes
[ALL ] checking for cos in -lm... yes
[ERROR] configure: error: *** unknown target vector
[ERROR] make[2]: *** [configure-bfd] Error 1

Any suggestions ?

Try preing binutils source folder with:

cd binutils

# Some sed magic to make autotools work on platforms with different
autotools version
# Works for binutils 2.20.1. May work for other versions.
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g' ./ ||
task_error "sed failed"
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g'
./libiberty/ || task_error "sed failed"
sed -i 's/ \[m4_fatal(\[Please use exactly Autoconf \]/
\[m4_errprintn(\[Please use exactly Autoconf \]/g' ./config/override.m4
|| task_error "sed failed"

autoconf || task_error "autoconf failed"
for d in bfd opcodes binutils ld gas gprof ; do
do_pushd ${d}
autoreconf || task_error "autoreconf in $d failed."

Per A.

Thanks Per,

I ran those lines from the shell but had to iterate the for loop by
hand. It went cleanly but what context where you intending that to be

They are actually run from a bash script.

OK , so do_push et al must be defined somewhere else in your script. I just substituted pushd and popd and it's fine.

It seems to have cleared the last error but when I restart ct-ng build I get a whole string of errors of the same type:

[INFO ] Installing binutils
[EXTRA] Configuring binutils
[EXTRA] Building binutils
/back/ts/ct-ng/targets/src/binutils-2.20.1/bfd/elf32-avr32.c:168: error:
'BFD_RELOC_AVR32_DIFF32' undeclared here (not in a function)
/back/ts/ct-ng/targets/src/binutils-2.20.1/bfd/elf32-avr32.c:169: error:
'BFD_RELOC_AVR32_DIFF16' undeclared here (not in a function)

Have I missed a patch somewhere ?
No, but for binutils there is an extra step when building:

binutils/configure \
--with-pkgversion="Whatever version string you would like"\
--target=avr32 \
--host=<host_platform> \
--build=<build_platform> \
--disable-nls \
make all-bfd TARGET-bfd=headers
# force reconfiguring
rm bfd/Makefile
make configure-host

See if this sequence helps!

Per A.

regards, Peter.


well not really. I used ct-ng to unpack and patch binutils and then ran
your sed bits by hand . So far all seems OK.


binutils/configure --target=avr32 --disable-nls --disable-werror
--host=i686-unknown-linux-gnu --build=i686-unknown-linux-gnu

checking for i686-unknown-linux-gnu-gcc... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no ???

make all-bfd TARGET-bfd=headers Makefile:26: *** missing separator. Stop.


More clearly documented than my earlier notes: here is the way I got it to build binutils using the above patches in a local ct-ng patch dir :

ct-ng build STOP=gmp+ # use ct-ng to fetch and patch binutils
cd targets/src/binutils-2.20.1
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g' ./ || echo "sed failed"
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g' ./libiberty/ || echo "sed failed"
sed -i 's/ \[m4_fatal(\[Please use exactly Autoconf \]/\[m4_errprintn(\[Please use exactly Autoconf \]/g' \
./config/override.m4 || echo "sed failed"

for d in bfd opcodes binutils ld gas gprof ; do
pushd ${d}
autoreconf     || echo  "autoreconf in $d failed."

./configure --target=avr32-unknown-none --prefix=${CT_TOP_DIR}/x-tools --disable-werror --disable-nls
make all-bfd TARGET-bfd=headers
rm bfd/Makefile
make configure-host
make install

Using gcc-4.3.3

That is mostly as shown in the following link, plus some help from Per ;)

I don't claim any more testing than "it builds" at this stage, since I have yet to hack ct-ng to continue from this point using the hand built binutils.

Neither do I have the hardware to test it yet. This exercise is to look at the feasibility of using avr32 platform. Setting up a linux based development system is a prerequisite.

I hadn't anticipated having to roll my sleeves up quite so far or so early or but that's why I'm checking all this out before committing to using avr32 .

If anyone is interested in binaries I can post the 10MB binary x-tool (x86-avr32) binutils tarball.


Attachment: binutils-unified.tar.gz
Description: application/gzip

For unsubscribe information see

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]