This is the mail archive of the crossgcc@sourceware.org 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/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?

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 ?

regards, Peter.

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


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