Re: avr32 build failures in linux-next

From: One Thousand Gnomes
Date: Thu Mar 10 2016 - 09:30:48 EST

On Wed, 9 Mar 2016 21:30:55 +0200
Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:

> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
> >>
> >> On Sat, Feb 6, 2016 at 7:28 PM, MÃns RullgÃrd <mans@xxxxxxxxx> wrote:
> >>
> >>> Not very surprising either. The number of people using Linux on avr32
> >>> is probably approximately zero, and if anyone is, they're likely still
> >>> running 2.6.32 or thereabouts.
> >>
> >>
> >> Once I tried up the topic about removal avr32 for good, but looks like
> >> it wasn't a good time. Maybe now is better? It would really reduce a
> >> burden on many drivers.
> >>
> > I would agree, as long as the maintainers agree. We don't want to repeat
> > the h8300 experience.
> So, are we going to agree that avr32 must be retired from next cycle?
> P.S. I have no idea how to fix this "ârelocation truncated to fit:
> R_AVR32_21Sâ", though I can test anything anyone propose.

It means the AVR32 tool chain generated a 21bit signed code relocation
then couldn't fix it up at link time. This probably simply means that
something called through anon_inode_getfile() is now more than 1MB away
from the call location, in which case you'll just need to debloat the
kernel until it fits again or re-order the link to cure it (if I had to
guess it'll be some kind of support function call and the compiler
support tends to end up one end of the binary not in the middle).

Could also be a linker bug (AVR32 has a few) or the toolchain writing
crap (check the .S file)

Unfortunately I don't believe the AVR32 binutils is bright enough to fix
up such relocations with a more locally inserted branch to set up a
branch to a 32bit target (which is not pretty). Reordering the link might
help if it happens to move the problem routines nearer each other but
it's not a real fix.