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

Attachment: binutils-unified.tar.gz
Description: application/gzip

--
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]