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
