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

[ng at piments dot com]

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