linux-kernel - Re: avr32 build failures in linux-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Mar 2016 14:29:38 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	Måns Rullgård <mans@...sr.com>,
	Hans-Christian Noren Egtvedt <egtvedt@...fundet.no>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	Haavard Skinnemoen <hskinnemoen@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: avr32 build failures in linux-next

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

> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@...ck-us.net> 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@...sr.com> 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.

Alan