Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752892Ab1CJWT1 (ORCPT ); Thu, 10 Mar 2011 17:19:27 -0500 Received: from smtp-out.google.com ([216.239.44.51]:45002 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751403Ab1CJWTZ convert rfc822-to-8bit (ORCPT ); Thu, 10 Mar 2011 17:19:25 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qgpm9o+7Ls0FY+KnYkd67CnX+4/sv6e4tb+Spcl5jcmWKbk+Iock4HQyzZlrRJu537 DC0SmEGqOfCq5aMZ5Nnw== MIME-Version: 1.0 In-Reply-To: References: <1299639325-10384-1-git-send-email-sjg@chromium.org> Date: Thu, 10 Mar 2011 14:19:20 -0800 X-Google-Sender-Auth: D8kd-JmqBZ2auByJMOfc2JKd8Fs Message-ID: Subject: Re: [RFC PATCH V2] ARM: Use generic BUG() handler From: Simon Glass To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, Russell King , Tony Lindgren , Nicolas Pitre , Catalin Marinas , Joe Perches , Laurent Pinchart , Alexander Shishkin , Phil Carmody , Rabin Vincent , linux-kernel@vger.kernel.org, Mikael Pettersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2402 Lines: 73 On Wed, Mar 9, 2011 at 1:51 AM, Dave Martin wrote: > On Wed, Mar 9, 2011 at 2:55 AM, Simon Glass wrote: >> +#ifdef CONFIG_THUMB2_KERNEL >> +#define BUG_INSTR_VALUE 0xf7f2 > > This isn't an undefined instruction... it's actually half of some > 32-bit Thumb instruction. Did you mean 0xdexx instead? Yes, will fix. >> +#define BUG_INSTR_TYPE ".hword " >> +#else >> +#define BUG_INSTR_VALUE 0xe7f001f2 >> +#define BUG_INSTR_TYPE ".word " >> +#endif >> + > > This works, but do we really need to split the definition of the bug > instruction into two macros? This is so that I can test for the correct instruction word in valid_bug_addr(). > > Unless you can see a use for calling _BUG() directly with a different > instruction value, of course... > >> + ? ? ? /* >> + ? ? ? * .exit.text is discarded at runtime, not link time, to deal with >> + ? ? ? * ?references from bug_table >> + ? ? ? */ >> + ? ? ? .exit.text : AT(ADDR(.exit.text)) { >> + ? ? ? ? ? ? ? EXIT_TEXT >> + ? ? ? } >> + >> + ? ? ? .exit.data : AT(ADDR(.exit.data)) { >> + ? ? ? ? ? ? ? EXIT_DATA >> + ? ? ? } > > This is the same unfortunate hack we have to do for other fixups, > because there's no way to separate out some of these entries in such a > way that they can be discarded at link time... ?I did have an idea for > an extention to gas which would allow fixups and similar data to be > emitted in separate ancillary sections which the linker can handle > sensibly, so that bug entries referencing .exit.text (for example) can > be discarded at link time. > > See http://sourceware.org/ml/binutils/2011-02/msg00004.html > > I haven't received any support for the idea so far though... Well yes, and some might even argue that calling BUG() in __exit code is not a great idea. Here we are adding in all exit data again which is about 8.5KB in my kernel. These two pages are then reclaimed at runtime. However, at present I don't see any alternative to this, and this is what is done on other architectures to support BUG(). > > Cheers > ---Dave > I will tidy this up, test it properly on Thumb and submit a patch. Regards, Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/