From patchwork Mon Jul 22 18:56:00 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Dooks X-Patchwork-Id: 2831552 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id C4984C0319 for ; Mon, 22 Jul 2013 18:56:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B7137202D1 for ; Mon, 22 Jul 2013 18:56:39 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6802A200FE for ; Mon, 22 Jul 2013 18:56:38 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1V1LHb-0007ho-7n; Mon, 22 Jul 2013 18:56:31 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1V1LHY-0003KV-TS; Mon, 22 Jul 2013 18:56:28 +0000 Received: from ducie-dc1.codethink.co.uk ([37.128.190.40]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1V1LHW-0003Jv-3y for linux-arm-kernel@lists.infradead.org; Mon, 22 Jul 2013 18:56:26 +0000 Received: from localhost (localhost [127.0.0.1]) by ducie-dc1.codethink.co.uk (Postfix) with ESMTP id 8DB784608AD; Mon, 22 Jul 2013 19:56:04 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at ducie-dc1.codethink.co.uk Received: from ducie-dc1.codethink.co.uk ([127.0.0.1]) by localhost (ducie-dc1.codethink.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEQchbgY+6OG; Mon, 22 Jul 2013 19:56:01 +0100 (BST) Received: from [192.168.24.134] (rainbowdash.dyn.ducie.codethink.co.uk [192.168.24.134]) by ducie-dc1.codethink.co.uk (Postfix) with ESMTPSA id 96D2B460592; Mon, 22 Jul 2013 19:56:00 +0100 (BST) Message-ID: <51ED8040.2020803@codethink.co.uk> Date: Mon, 22 Jul 2013 19:56:00 +0100 From: Ben Dooks Organization: Codethink Limited. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Nicolas Pitre Subject: Re: [PATCH 4/4] ARM: set --be8 when linking modules References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk> <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk> <20130722170500.GC19639@codeaurora.org> <51ED69CA.3030501@codethink.co.uk> In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130722_145626_284842_141AD086 X-CRM114-Status: GOOD ( 20.92 ) X-Spam-Score: -3.4 (---) Cc: ian.molton@codethink.co.uk, Stephen Boyd , paul.sherwood@codethink.co.uk, linux-arm-kernel@lists.infradead.org, rob.taylor@codethink.co.uk X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 22/07/13 19:53, Nicolas Pitre wrote: > On Mon, 22 Jul 2013, Ben Dooks wrote: > >> On 22/07/13 18:05, Stephen Boyd wrote: >>> On 07/22, Ben Dooks wrote: >>>> To avoid having to make every text section swap the instruction order >>>> of all instructions, make sure modules are built also built with --be8 >>>> (as is the current kernel final link). >>>> >>>> If we do not do this, we would end up having to swap all instructions >>>> when loading a module, instead of just the instructions that we are >>>> applying ELF relocations to. >>>> >>> >>> If someone tries to load a be8 module on a non-be8 kernel will it >>> still work? Or should we add an extra version magic string in >>> asm/module.h to prevent that? >> >> The ELF header changes the EI_DATA field in the ei_ident from >> ELFDATA2LSB to ELFDATA2MSB when compiling so we should be able >> to detect these when loading. >> >> I have not checked to see if the kernel correctly checks for this. >> >> I do not think it currently checks the ei_flags field for the >> EF_ARM_BE8 in ABI 4 and 5. I am not sure if this is really important? > > If the information is already there and easily accessible, then it > should be used. > > > Nicolas I have something like this, it does not mess things up loading BE8 binaries on my current system. I think we're building stuff for EABI4 but haven't checked. Senior Engineer Codethink - Providing Genius diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c index d0d1e83..3b0351c 100644 --- a/arch/arm/kernel/elf.c +++ b/arch/arm/kernel/elf.c @@ -34,6 +34,15 @@ int elf_check_arch(const struct elf32_hdr *x) if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) return 0; } + + if ((eflags & EF_ARM_EABI_MASK) >= EF_ARM_EABI_VER4) { + if (eflags & EF_ARM_BE8) { + if (!IS_ENABLED(CONFIG_ARM_CPU_BE8)) + return 1; + } else if (IS_ENABLED(CONFIG_ARM_CPU_BE8)) + return 1; + } + -- Ben Dooks http://www.codethink.co.uk/