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]

Message-ID: <yw1xoabtg33u.fsf@unicorn.mansr.com>
Date:	Sat, 06 Feb 2016 17:28:37 +0000
From:	Måns Rullgård <mans@...sr.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Hans-Christian Noren Egtvedt <egtvedt@...fundet.no>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	Haavard Skinnemoen <hskinnemoen@...il.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: avr32 build failures in linux-next

Guenter Roeck <linux@...ck-us.net> writes:

> On 02/06/2016 06:01 AM, Måns Rullgård wrote:
>> Hans-Christian Noren Egtvedt <egtvedt@...fundet.no> writes:
>>
>>>>> Example for avr32:defconfig:
>>>>>
>>>>> fs/built-in.o: In function `anon_inode_getfile':
>>>>> (.text+0x2ae90): relocation truncated to fit: R_AVR32_21S against
>>>>> `.text'+296c0
>>>>>
>>>>> All builds but avr32:allnoconfig fail with such truncated relocations.
>>>
>>> Weirdly I do not get this when I build torvalds/master with allnoconfig.
>>>
>>> The avr32 kernel was never very fond of CONFIG_CC_OPTIMIZE_FOR_SIZE=n, it
>>> was always built with CONFIG_CC_OPTIMIZE_FOR_SIZE=y for actual usage.
>>
>> 4.5-rc1 builds and runs with CONFIG_CC_OPTIMIZE_FOR_SIZE=n here.  It's a
>> fairly minimal config though.
>>
>
> 4.5-rcX is not the problem. I was talking about linux-next.

I know, I was merely providing another data point.

> Disabling CONFIG_CC_OPTIMIZE_FOR_SIZE does not make a difference. Same
> problem.
>
>>>>> Toolchain used is the old gcc 4.2.4 toolchain from kernel.org. I have been
>>>>> unable to find or build newer versions of gcc for avr32.
>>>>>
>>>>> Does anyone know if a more recent toolchain for avr32 is available ?
>>>>
>>>> https://sourceware.org/ml/crossgcc/2015-10/msg00050.html
>>>> says avr32 has been depreciated.
>>>
>>> Last release of avr32-linux GCC was the 4.2.4 patches in Buildroot
>>> for AVR32.
>>>
>>> Atmel never upstreamed the AVR32 patches for GCC.
>>
>> There are patches for gcc 4.4.3 at
>> http://distribute.atmel.no/tools/opensource/avr32-gcc/
>> The patches apply with only trivial fixes to 4.4.7 as well.  I tried
>> forward-porting to something newer, but my knowledge gcc internal voodoo
>> wasn't sufficient.
>>
> I managed to build avr32 gcc 4.4.7 from
> http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/
> after making a couple of changes in the gcc source to make its first
> stage build with a recent version of gcc (looks like one can not build
> gcc 4.4.7 with gcc 5.2 without fixing it up first ;-).
>
> No difference. If anything, the situation is worse, since it produces lots of
>
> avr32-ld:built in linker script:15: warning: memory region `FLASH' not declared
> avr32-ld:built in linker script:140: warning: memory region `CPUSRAM' not declared

That looks like you're trying to use a toolchain configured for bare
metal uC environment.

> in addition to the final 'relocation truncated to fit' error.
>
> Since the message is produced by the linker, maybe this isn't even a compiler
> problem but a problem with binutils.

"Relocation truncated to fit" usually means the compiler used a relative
addressing mode to access something that ended up being too far away in
the final link.  Sometimes this is caused by using compiler flags for a
"small" memory model (text+data less than some limit) when a "large"
setting should have been used due to the size of the thing being built.
That's not the case here, however, since there are no such flags for
AVR32.  This means it's most likely either a compiler bug or a bug in
hand-written assembly code.

>>>>> Another question is if the avr32 kernel still supported, or if I should
>>>>> just stop trying to build test it. Any thoughts ?
>>>>
>>>> I have already stopped building it.
>>>
>>> I build the kernel and try to fix small issues here and there.
>>
>> Even when it builds, it often doesn't work since non-DT support has
>> bitrotted in many drivers.
>>
> Not very encouraging.

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.

-- 
Måns Rullgård