BFD does not support target avr32-unknown-none.
ng@piments.com
ng@piments.com
Mon Feb 21 10:48:00 GMT 2011
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.
>>>>>>
>>>>>> 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.
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list