From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754869AbbDHVTz (ORCPT ); Wed, 8 Apr 2015 17:19:55 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:65275 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753838AbbDHVTx (ORCPT ); Wed, 8 Apr 2015 17:19:53 -0400 Message-ID: <55259B76.8030602@nod.at> Date: Wed, 08 Apr 2015 23:19:50 +0200 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Chen Gang , realmz6@gmail.com CC: adi-buildroot-devel@lists.sourceforge.net, "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] blackfin: Makefile: Skip reloc overflow issue when COMPILE_TEST enabled References: <5525992C.6090906@nod.at> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 08.04.2015 um 23:16 schrieb Chen Gang: > On 4/9/15 05:10, Richard Weinberger wrote: >> Am 08.04.2015 um 23:05 schrieb Chen Gang: >>> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel >>> is too big, it may be overwritten, the related issue: >>> >>> LD init/built-in.o >>> init/built-in.o: In function `do_early_param': >>> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o) >>> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o) >>> init/built-in.o: In function `unknown_bootoption': >>> >>> blackfin is for embedded system, the size limitition is acceptable, so >>> it is not the real world issue, which should be skipped if COMPILE_TEST >>> enabled. >> >> You're again papering over the real issue. >> COMPILE_TEST is only one way to generate a too big kernel. >> The right thing is to blow up and warn the user. >> > > If COMPILE_TEST is not set, the right thing is to blow up and warn the > user. > > But for me, if COMPILE_TEST is set, the right thing is to warn the user > without blowing up (the user already know about it -- he/she only care > about the building test). How can you be sure that the issue you found is a) worth ignoring b) not solvable? As you paper of it by adding an #ifdef COMPILE_TEST which is very hacky IMHO. Thanks, //richard