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

[Per Arnold Blaasmo <root at sjogate2 dot atmel dot com>]

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.
> 
> 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.
> 
> -- 
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 
> 


--
For unsubscribe information see http://sourceware.org/lists.html#faq