problem with AVR cross compiler

problem with AVR cross compiler

[Egbert Jan van den Bussche]

Hello,

I was building a cross-compiler (avr-gcc) from the 4.2.3 sources on my 
Mandriva 2008.0 system but an error occured. Dunno if this is the right 
place to drop this but I give it a try.
I will try previous versions 4.2.2 and 4.2.1 to see if this error goes away.

/var/ftp/Linux/AVR-GCC/gcc-4.2.3/avr-gcc/./gcc/xgcc 
-B/var/ftp/Linux/AVR-GCC/gcc-4.2.3/avr-gcc/./gcc/ -B/usr/local/avr/bin/ 
-B/usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem 
/usr/local/avr/sys-include -O2  -O2 -g -O2  -DIN_GCC -DCROSS_COMPILE   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition  -isystem ./include  -DDF=SF -Dinhibit_libc 
-mcall-prologues -Os -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include 
-I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber 
-I../libdecnumber -mmcu=avr35 -DL_mulsi3 -xassembler-with-cpp -c 
../../gcc/config/avr/libgcc.S -o libgcc/avr35/_mulsi3.o
../../gcc/config/avr/libgcc.S: Assembler messages:
../../gcc/config/avr/libgcc.S:280: Error: illegal opcode movw for mcu avr3
../../gcc/config/avr/libgcc.S:282: Error: illegal opcode movw for mcu avr3
make[3]: *** [libgcc/avr35/_mulsi3.o] Error 1
make[3]: Leaving directory `/var/ftp/Linux/AVR-GCC/gcc-4.2.3/avr-gcc/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/var/ftp/Linux/AVR-GCC/gcc-4.2.3/avr-gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/var/ftp/Linux/AVR-GCC/gcc-4.2.3/avr-gcc'
make: *** [all] Error 2

Best regards,
Egbert Jan van  den Bussche (NL)
egbert@vandenbussche.nl

Re: problem with AVR cross compiler

[Brian Dessent]

Egbert Jan van den Bussche wrote:

> ../../gcc/config/avr/libgcc.S: Assembler messages:
> ../../gcc/config/avr/libgcc.S:280: Error: illegal opcode movw for mcu avr3
> ../../gcc/config/avr/libgcc.S:282: Error: illegal opcode movw for mcu avr3

The errors are from the assembler, not from gcc.  You might try updating
to the latest version of binutils (which contains the assembler) which
might have updated or fixed AVR support.

Brian

Re: problem with AVR cross compiler

[Egbert Jan van den Bussche]

Brian Dessent wrote:
> Egbert Jan van den Bussche wrote:
>
>   
>> ../../gcc/config/avr/libgcc.S: Assembler messages:
>> ../../gcc/config/avr/libgcc.S:280: Error: illegal opcode movw for mcu avr3
>> ../../gcc/config/avr/libgcc.S:282: Error: illegal opcode movw for mcu avr3
>>     
>
> The errors are from the assembler, not from gcc.  You might try updating
> to the latest version of binutils (which contains the assembler) which
> might have updated or fixed AVR support.
>
> Brian
>   
Thanks Brian. I went back just one release (GCC 4.2.2) and building 
AVR-GCC is OK again. I'll try to investigate  bit more. I did use the 
2.18 binutils which compiled just fine on the same machine. There was an 
issue some time ago (in the 4.1.1 era) with libssp. Maybe I was bitten 
by that. During Configure you must specify --disable-libssp. This comes 
all from the avwiki (avrwiki.com) and I have no idea what libssp does.

Regards,
Egbert Jan

Re: problem with AVR cross compiler

[Brian Dessent]

Egbert Jan van den Bussche wrote:

> Thanks Brian. I went back just one release (GCC 4.2.2) and building
> AVR-GCC is OK again. I'll try to investigate  bit more. I did use the
> 2.18 binutils which compiled just fine on the same machine. There was an

Since binutils and gcc are not released in sync, you may require
something newer than 2.18 (which was released 2007-08-28) to go with
4.2.3 (released 2008-02-01.)

> issue some time ago (in the 4.1.1 era) with libssp. Maybe I was bitten
> by that. During Configure you must specify --disable-libssp. This comes
> all from the avwiki (avrwiki.com) and I have no idea what libssp does.

libssp is a library that's part of the stack-smashing protection system
that's activated with -fstack-check.  It isn't available on all targets,
and it's likely that AVR is one such target.  Ideally it should default
to disabled for those targets that don't support it, but sometimes those
details aren't looked after.  I don't think this is related.

Brian

Re: problem with AVR cross compiler

[Egbert Jan van den Bussche]

Brian Dessent wrote:
> Egbert Jan van den Bussche wrote:
>
>   
>> Thanks Brian. I went back just one release (GCC 4.2.2) and building
>> AVR-GCC is OK again. I'll try to investigate  bit more. I did use the
>> 2.18 binutils which compiled just fine on the same machine. There was an
>>     
>
> Since binutils and gcc are not released in sync, you may require
> something newer than 2.18 (which was released 2007-08-28) to go with
> 4.2.3 (released 2008-02-01.)
>   
I'll see what newer is available. I just had a look in libgcc.S and 
there is a switch that seems related.

/* Most of the functions here are called directly from avr.md
   patterns, instead of using the standard libcall mechanisms.
   This can make better code because GCC knows exactly which
   of the call-used registers (not all of them) are clobbered.  */

        .section .text.libgcc, "ax", @progbits

        .macro  mov_l  r_dest, r_src
#if defined (__AVR_HAVE_MOVW__)
        movw    \r_dest, \r_src
#else
        mov     \r_dest, \r_src
#endif
        .endm

I'll compare this with 4.2.2

>   
>> issue some time ago (in the 4.1.1 era) with libssp. Maybe I was bitten
>> by that. During Configure you must specify --disable-libssp. This comes
>> all from the avwiki (avrwiki.com) and I have no idea what libssp does.
>>     
>
> libssp is a library that's part of the stack-smashing protection system
> that's activated with -fstack-check.  It isn't available on all targets,
> and it's likely that AVR is one such target.  Ideally it should default
> to disabled for those targets that don't support it, but sometimes those
> details aren't looked after.  I don't think this is related.
>
> Brian
>   
The libssp problem mentioned in the avrwiki seems to have gone away; it 
doesn't mak any difference whether I use the --disable-libssp or not.


Egbert jan

Re: problem with AVR cross compiler

[Egbert Jan van den Bussche]

Hi Brian,

There seems to be a new 'class' AVR35, introduced in 4.2.3. Would it be 
possible to find out who was responsible for this change/patch? He could 
tell if a newer binutils was used for his testing.

Below are the diffs for avr.c, avr.h, and t-avr in the source tree 
/gcc-4.2.3/gcc/config/avr.

[egbert@server avr]$ diff avr.c 
/var/ftp/Linux/AVR-GCC/gcc-4.2.3/gcc/config/avr/avr.c
145a146
 >   { 0, 0, 1, 1, "__AVR_ARCH__=35"},
159a161
 >   ARCH_AVR35,
214a217,220
 >     /* Classic + MOVW + JMP/CALL.  */
 >   { "avr35",        ARCH_AVR35, NULL },
 >   { "at90usb82",    ARCH_AVR35, "__AVR_AT90USB82__" },
 >   { "at90usb162",   ARCH_AVR35, "__AVR_AT90USB162__" },
265,266d270
<   { "at90usb82",    ARCH_AVR5, "__AVR_AT90USB82__" },
<   { "at90usb162",   ARCH_AVR5, "__AVR_AT90USB162__" },

[egbert@server avr]$ diff avr.h 
/var/ftp/Linux/AVR-GCC/gcc-4.2.3/gcc/config/avr/avr.h
736c736
< #define ASM_SPEC "%{mmcu=avr25:-mmcu=avr2;\
---
 > #define ASM_SPEC "%{mmcu=avr25:-mmcu=avr2;mmcu=avr35:-mmcu=avr3;\
762c762,764
<   mmcu=at76*:-m avr3}\
---
 >   mmcu=at76*|\
 >   mmcu=at90usb82|\
 >   mmcu=at90usb162:-m avr3}\
772c774,775
<   mmcu=at90usb*|\
---
 >   mmcu=at90usb64*|\
 >   mmcu=at90usb128*|\
846a850,851
 > %{mmcu=at90usb162|mmcu=avr35:crtusb162.o%s} \
 > %{mmcu=at90usb82:crtusb82.o%s} \
893,894d897
< %{mmcu=at90usb82:crtusb82.o%s} \
< %{mmcu=at90usb162:crtusb162.o%s} \

[egbert@server avr]$ diff t-avr 
/var/ftp/Linux/AVR-GCC/gcc-4.2.3/gcc/config/avr/t-avr
40,41c40,41
< MULTILIB_OPTIONS = mmcu=avr2/mmcu=avr25/mmcu=avr3/mmcu=avr4/mmcu=avr5
< MULTILIB_DIRNAMES = avr2 avr25 avr3 avr4 avr5
---
 > MULTILIB_OPTIONS = 
mmcu=avr2/mmcu=avr25/mmcu=avr3/mmcu=avr35/mmcu=avr4/mmcu=avr5
 > MULTILIB_DIRNAMES = avr2 avr25 avr3 avr35 avr4 avr5
61a62,63
 >       mmcu?avr35=mmcu?at90usb82 \
 >       mmcu?avr35=mmcu?at90usb162 \
108,109d109
<       mmcu?avr5=mmcu?at90usb82 \
<       mmcu?avr5=mmcu?at90usb162 \
[egbert@server avr]$


Egbert Jan



Brian Dessent wrote:
> Egbert Jan van den Bussche wrote:
>
>   
>> Thanks Brian. I went back just one release (GCC 4.2.2) and building
>> AVR-GCC is OK again. I'll try to investigate  bit more. I did use the
>> 2.18 binutils which compiled just fine on the same machine. There was an
>>     
>
> Since binutils and gcc are not released in sync, you may require
> something newer than 2.18 (which was released 2007-08-28) to go with
> 4.2.3 (released 2008-02-01.)
>
>   
>> issue some time ago (in the 4.1.1 era) with libssp. Maybe I was bitten
>> by that. During Configure you must specify --disable-libssp. This comes
>> all from the avwiki (avrwiki.com) and I have no idea what libssp does.
>>     
>
> libssp is a library that's part of the stack-smashing protection system
> that's activated with -fstack-check.  It isn't available on all targets,
> and it's likely that AVR is one such target.  Ideally it should default
> to disabled for those targets that don't support it, but sometimes those
> details aren't looked after.  I don't think this is related.
>
> Brian
>   

Re: problem with AVR cross compiler

[Brian Dessent]

Egbert Jan van den Bussche wrote:

> There seems to be a new 'class' AVR35, introduced in 4.2.3. Would it be
> possible to find out who was responsible for this change/patch? He could
> tell if a newer binutils was used for his testing.

This seems to be the patch you need, committed to binutils on
2008-01-14: <http://sourceware.org/ml/binutils/2008-01/msg00165.html>. 
So, use binutils from current CVS.

Brian

Re: problem with AVR cross compiler

[Egbert Jan van den Bussche]

Brian Dessent wrote:
> Egbert Jan van den Bussche wrote:
>
>   
>> There seems to be a new 'class' AVR35, introduced in 4.2.3. Would it be
>> possible to find out who was responsible for this change/patch? He could
>> tell if a newer binutils was used for his testing.
>>     
>
> This seems to be the patch you need, committed to binutils on
> 2008-01-14: <http://sourceware.org/ml/binutils/2008-01/msg00165.html>. 
> So, use binutils from current CVS.
>
> Brian
>   
So it seems binutils is the cause. Thanks for finding out. I'll see what 
to do; get the cvs source or stick with 4.2.2. I'm not using the devices 
concerned here.

CU
Egbert Jan