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 20/02/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.

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.


OK , I finally got this to build !

One slight difference from the last post from Per I found after refering to this:

configure needs to be called from the same level as the other commands not from the binutils subdir.

ct-ng build
#break after extracting and patching stage.
cd targets/src/binutils-2.20.1
sed ...
sed ...
sed ...
for d ... do .. done
./configure --target=avr32-unknown-none --prefix={$CTNGDIR}/x-tools --disable-werror --disable-nls

make all-bfd TARGET-bfd=headers
 rm bfd/Makefile
 make configure-host
 make install

Many thanks for Per for the help.

Now to see if I can integrate this into ct-ng with all this tweeking going on...


For unsubscribe information see

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