From patchwork Mon Feb 8 17:01:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 61416 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp1553234lbl; Mon, 8 Feb 2016 09:03:10 -0800 (PST) X-Received: by 10.98.31.84 with SMTP id f81mr43434149pff.98.1454950990385; Mon, 08 Feb 2016 09:03:10 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id n62si47636787pfa.183.2016.02.08.09.03.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2016 09:03:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org; dkim=neutral (body hash did not verify) header.i=@linaro.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aSpCT-0000cR-NW; Mon, 08 Feb 2016 17:02:09 +0000 Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aSpC7-0008Q5-E8 for linux-arm-kernel@lists.infradead.org; Mon, 08 Feb 2016 17:01:53 +0000 Received: by mail-io0-x22a.google.com with SMTP id g73so201736575ioe.3 for ; Mon, 08 Feb 2016 09:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W9vVE3yM6xZJqfhvgf1RYOZMFHT198XzbRlLrmRT5Bo=; b=hbsKsuuexwnb24o1/HWI8etIIDMcHlL7+QJ7OA42ZKchTdHltGEcruWon0p1ax+rEW 9pOpVf+9kM/s4V2F0svu1zoNIDKLVvQrEHirlK50ngvhCZWM2/X67CxAHgwA+nFXlnXs FgBYR8ZeqDOPcF3sm0i+g/CL18H6PgS6JL5sU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W9vVE3yM6xZJqfhvgf1RYOZMFHT198XzbRlLrmRT5Bo=; b=huNhs9Dhz69edqkl3PR2a+VEArwq5dFL78csiprbGPrIeORfIKxYQ5GxkfmKu4Oml5 tla1vnTKYHG/0rLJ5tZ3koMZgN8iCIxhidoyLyl8c5F5NrnYBq+X3ujxOc9AiaQcThDh nRiggf+z/9uO+BN9c5X40w2MzENhtnMSwUO/FhGw6XgJq8G5q12qlRPx/gJywFBG3e1k i+NEOJbvQE0KMdiOwsiBwl/2rIoiWgFnxUSmIy/7T5P7doYjERJtE6gcOLlEDTXnrsEW lQuWaIN4uUqEiyIyIMvh85mdC2Q94F3gtR64Zx0bafWJoeWDCZ2Vae7a6E/rzG0bQeuP MmTg== X-Gm-Message-State: AG10YOSk8m3qC/a+5Vm6x5v+GG30skYFYx/PrjLe9l3OGecADqaKaWasQ8nvip8BCHBDtZ48KK0vCeYGe0kHQ+RD MIME-Version: 1.0 X-Received: by 10.107.18.199 with SMTP id 68mr7695845ios.130.1454950886155; Mon, 08 Feb 2016 09:01:26 -0800 (PST) Received: by 10.36.29.6 with HTTP; Mon, 8 Feb 2016 09:01:26 -0800 (PST) In-Reply-To: <20160208163935.GN10826@n2100.arm.linux.org.uk> References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org> <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org> <20160203000351.GX10826@n2100.arm.linux.org.uk> <20160203091331.GB10826@n2100.arm.linux.org.uk> <20160208163935.GN10826@n2100.arm.linux.org.uk> Date: Mon, 8 Feb 2016 18:01:26 +0100 Message-ID: Subject: Re: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA From: Ard Biesheuvel To: Russell King - ARM Linux X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160208_090148_030125_9E2185FA X-CRM114-Status: GOOD ( 23.99 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2607:f8b0:4001:c06:0:0:0:22a listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linus Walleij , Nicolas Pitre , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , Mark Brown Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On 8 February 2016 at 17:39, Russell King - ARM Linux wrote: > On Wed, Feb 03, 2016 at 10:16:46AM +0100, Ard Biesheuvel wrote: >> There are 34 section headers, starting at offset 0x10a6e60: >> >> Section Headers: >> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al >> [15] .notes NOTE c0c34020 a34020 000024 00 AX 0 0 4 >> [16] .vectors PROGBITS 00000000 a40000 000020 00 AX 0 0 2 >> [17] .stubs PROGBITS 00001000 a41000 0002c0 00 AX 0 0 32 >> [18] .init.text PROGBITS c0c352e0 a452e0 06b1b8 00 AX 0 0 32 > ... >> Section Headers: >> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al >> [15] .notes NOTE c0c34020 a34020 000024 00 AX 0 0 4 >> [16] .stubs PROGBITS c0c35000 a35000 0002c0 00 AX 0 0 32 >> [17] .vectors PROGBITS c0c34000 a44000 000020 00 AX 0 0 2 >> [18] .init.text PROGBITS c0c352e0 a452e0 06b1b8 00 AX 0 0 32 > > Sorry, but I'm going to re-iterate my objection, and I believe that > because you're looking at readelf's output, you're making assumptions > when interpreting its output. > > These figures do not truely describe how the file is laid out. The > tool to use for this is objdump -h. Let's compare: > > $ readelf -S vmlinux > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [13] .notes NOTE c093afd0 93afd0 000024 00 AX 0 0 4 > [14] .vectors PROGBITS 00000000 940000 000020 00 AX 0 0 4 > [15] .stubs PROGBITS 00001000 941000 0002c0 00 AX 0 0 32 > [16] .init.text PROGBITS c093b2e0 94b2e0 04862c 00 AX 0 0 32 > > $ objdump -h vmlinux > Sections: > Idx Name Size VMA LMA File off Algn > 12 .notes 00000024 c093afd0 c093afd0 0093afd0 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 13 .vectors 00000020 00000000 c093b000 00940000 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 14 .stubs 000002c0 00001000 c093b020 00941000 2**5 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 15 .init.text 0004862c c093b2e0 c093b2e0 0094b2e0 2**5 > CONTENTS, ALLOC, LOAD, READONLY, CODE > > Note that objdump -h has one additional piece of information here: the > LMA - load memory address. This tells us where the file contents > (offset into the ELF file at "File off") are to be loaded into memory, > as opposed to the VMA which describes where (at run time) the object is > to be found. > > With this new information, we can see that .vectors is loaded to > 0xc093b000, and occupies only 32 bytes in the binary memory image, even > though it occupies 4k in the ELF file.) .stubs is loaded at 0xc093b020, > and occupies 0x2c0 bytes. Furthermore, we can see .init.text is located > at 0xc093b2e0. > > So, there is no memory wastage here - .vectors, .stubs and the init text > are all packed tightly together. That's something which the readelf -S > output doesn't show us. > > Please, replace the readelf -S output with objdump -h output so that we > can see what's /really/ going on here. > OK, fair enough. Before: Sections: Idx Name Size VMA LMA File off Algn 14 .notes 00000024 c0c90030 c0c90030 00a90030 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 15 .vectors 00000020 00000000 c0c91000 00aa0000 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 16 .stubs 000002c0 00001000 c0c91020 00aa1000 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 17 .init.text 0006b250 c0c912e0 c0c912e0 00aa12e0 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE and after 14 .notes 00000024 c0c90030 c0c90030 00a90030 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 15 .stubs 000002c0 c0c91000 c0c91000 00a91000 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 16 .vectors 00000020 c0c90000 c0c912c0 00aa0000 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 17 .init.text 0006b250 c0c912e0 c0c912e0 00aa12e0 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE So, apart from the fact that .vectors and .stubs are reordered, nothing changes, and the LMA footprint is identical. > In any case, I still don't like your patch. At least having these at 0 > and 0x1000 means that (for some CPUs) they are located at the real VMA > address that they may appear at, though for modern CPUs, locating them > at 0xffff0000 and 0xffff1000 VMA would be more reasonable. This has the > advantage that (jtag) debuggers are able to correctly parse the vmlinux > file and insert breakpoints into the vectors. > 0xffff0000 and 0xffff1000 work for me. I am trying to get rid of this dodgy workaround in scripts/link-vmlinux.sh(85): if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET" fi which is there because perf does not like seeing the zero based kernel symbol addresses, and only fixes the XIP_KERNEL=n case anyway. Alternatively, this issue can be solved by making all stubs symbols strictly local (or absolute), i.e., something like below. Would that be preferable to you? It also fixes the perf issue for both XIP_KERNEL=y and =n, but keeps .vectors and .stubs where they are. -- Ard. ---------8<------------ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 788e40c1254f..c5c50c70c080 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -1027,7 +1027,7 @@ __kuser_helper_end: .macro vector_stub, name, mode, correction=0 .align 5 -vector_\name: +.Lvector_\name: .if \correction sub lr, lr, #\correction .endif @@ -1056,7 +1056,7 @@ vector_\name: mov r0, sp ARM( ldr lr, [pc, lr, lsl #2] ) movs pc, lr @ branch to handler in SVC mode -ENDPROC(vector_\name) +ENDPROC(.Lvector_\name) .align 2 @ handler addresses follow this label @@ -1064,14 +1064,15 @@ ENDPROC(vector_\name) .endm .section .stubs, "ax", %progbits +.Lstubs_start: @ This must be the first word .word vector_swi -vector_rst: +.Lvector_rst: ARM( swi SYS_ERROR0 ) THUMB( svc #0 ) THUMB( nop ) - b vector_und + b .Lvector_und /* * Interrupt dispatcher @@ -1173,8 +1174,8 @@ vector_rst: * (they're not supposed to happen, and won't happen in 32-bit data mode). */ -vector_addrexcptn: - b vector_addrexcptn +.Lvector_addrexcptn: + b .Lvector_addrexcptn /*============================================================================= * FIQ "NMI" handler @@ -1202,18 +1203,18 @@ vector_addrexcptn: .long __fiq_svc @ f .globl vector_fiq_offset - .equ vector_fiq_offset, vector_fiq + .equ vector_fiq_offset, .Lvector_fiq - .Lstubs_start + 0x1000 .section .vectors, "ax", %progbits .L__vectors_start: - W(b) vector_rst - W(b) vector_und + W(b) .Lvector_rst + W(b) .Lvector_und W(ldr) pc, .L__vectors_start + 0x1000 - W(b) vector_pabt - W(b) vector_dabt - W(b) vector_addrexcptn - W(b) vector_irq - W(b) vector_fiq + W(b) .Lvector_pabt + W(b) .Lvector_dabt + W(b) .Lvector_addrexcptn + W(b) .Lvector_irq + W(b) .Lvector_fiq .data