BFD does not support target avr32-unknown-none.

ng@piments.com ng@piments.com
Sun Feb 27 03:28:00 GMT 2011 

On 02/20/11 10:04, ng@piments.com wrote:
> On 02/18/11 13:02, Per Arnold Blaasmo wrote:
>> On 18. feb. 2011 11:40, ng@piments.com wrote:
>>>
>>> On 02/18/11 10:11, Per Arnold Blaasmo wrote:
>>>> On 18. feb. 2011 02:37, ng@piments.com wrote:
>>>>> On 02/17/11 17:41, ng@piments.com wrote:
>>>>>> On 02/15/11 16:07, Per Arnold Blåsmo wrote:
>>>>>>> Have a look at http://distribute.atmel.no/tools/opensource/
>>>>>>> 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, ng@piments.com wrote:
>>>>>>>> On 15/02/11 00:07, Yann E. MORIN wrote:
>>>>>>>>> Peter, All,
>>>>>>>>>
>>>>>>>>> On Monday 14 February 2011 23:39:19 ng@piments.com 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
>>>>>>>>>> find
>>>>>>>>>> any
>>>>>>>>>> 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):
>>>>>>>>> http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> BFD
>>>>>>>>> with
>>>>>>>>> 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
>>>>>>>> and
>>>>>>>> # 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
>>>>>>>> $RPM_BUILD_ROOT/%{_libdir}/lib{bfd*,opcodes*,iberty*,mmalloc*}
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Yann E. MORIN.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks Per, it looks like that is more upto date than what I was
>>>>>> using
>>>>>> from the other download.
>>>>>>
>>>>>>
>>>>>> All:
>>>>>>
>>>>>> 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
>>>>>> binutils
>>>>>> 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
>>>>>> here;
>>>>>> 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
>>>>>> ../avr32-binutils-trunk/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
>>>>>> AC_DEFUN([_GCC_AUTOCONF_VERSION_CHECK],
>>>>>> [m4_if(m4_defn([_GCC_AUTOCONF_VERSION]),
>>>>>> m4_defn([m4_PACKAGE_VERSION]), [],
>>>>>> - [m4_fatal([Please use exactly Autoconf ]_GCC_AUTOCONF_VERSION[
>>>>>> instead
>>>>>> 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])[
>>>>>> _GCC_AUTOCONF_VERSION_CHECK
>>>>>>
>>>>>>
>>>>>>
>>>>>> comparing the formats it seems like they were not created in the same
>>>>>> way.
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>> TIA,.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> For unsubscribe information see http://sourceware.org/lists.html#faq
>>>>>>
>>>>>>
>>>>>
>>>>> 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
>>>>> bfd_elf32_avr32_vec
>>>>> [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' ./configure.ac ||
>>>> task_error "sed failed"
>>>> sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g'
>>>> ./libiberty/configure.ac || 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."
>>>> do_popd
>>>> done
>>>>
>>>> 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
>>> run?
>>
>> 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
>>> [ERROR]
>>> /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)
>>> [ERROR]
>>> /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"\
>> --with-bugurl="http://www.atmel.com/avr"\
>> --target=avr32 \
>> --host=<host_platform> \
>> --build=<build_platform> \
>> --prefix=<PREFIX>\
>> --disable-nls \
>> --disable-werror
>> make all-bfd TARGET-bfd=headers
>> # force reconfiguring
>> rm bfd/Makefile
>> make configure-host
>> make
>>
>> See if this sequence helps!
>>
>> Per A.
>>
>>
>>>
>>> regards, Peter.
>>>
>>>
>
> Hi,
>
> 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.
>
> However:
>
> binutils/configure --target=avr32 --disable-nls --disable-werror
> --prefix=/back/ts/ct-ng/x-tools/avr32-unknown-none
> --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.
>
>
> regards.
>

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' ./configure.ac || echo "sed 
failed"
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g' ./libiberty/configure.ac || 
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"
  autoconf

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

./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
  make install


Using gcc-4.3.3

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

http://avr32linux.org/twiki/bin/view/Main/BinutilsPatches


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.

Regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils-unified.tar.gz
Type: application/gzip
Size: 169413 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/crossgcc/attachments/20110227/6cc151cb/attachment.gz>
-------------- next part --------------
--
For unsubscribe information see http://sourceware.org/lists.html#faq

More information about the crossgcc mailing list