From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71673 invoked by alias); 3 Mar 2020 15:06:47 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 71665 invoked by uid 89); 3 Mar 2020 15:06:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 15:06:45 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BDD03FEC; Tue, 3 Mar 2020 07:06:43 -0800 (PST) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.78.81]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 46E6B3F6C4; Tue, 3 Mar 2020 07:06:43 -0800 (PST) Subject: Re: impredictable alignment on ARM To: Alexandre Oliva , binutils@sourceware.org References: From: "Richard Earnshaw (lists)" Message-ID: Date: Tue, 03 Mar 2020 15:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2020-03/txt/msg00048.txt On 18/02/2020 01:21, Alexandre Oliva wrote: > Consider the following asm input: > > .thumb > .text > ldr r1, 0f > 0f: .word 0x12345678 > > In this case, we report the word is misaligned and fail, though the > section is aligned to 2-byte boundaries, so the word *might* be properly > aligned, after all, if only the previous linked section enabled the text > section above to start 2 bytes after a 4-byte aligned address. Anyway, > we probably don't want to worry about this case. > > However, I think we should be concerned about the converse case: > > .thumb > .text > ldr r1, 0f > ldr r2, 1f > 0f: .word 0x01234567 > 1f: .word 0x89abcdef > nop > > We do NOT report an error here, but if this text segment gets placed at > a 2-byte offset from a 4-byte aligned address (e.g., link the object > file in twice), the second pair will have misaligned words, and the > PC-relative offsets will resolve to aligned words that contain only part > of the word to be loaded. > > > The following patchlet arranges for us to complain when the target of > such an ldr doesn't ensure the expected alignment. However, it's not > quite enough to solve the general problem. Consider: > > .thumb > .text > ldr sp, 0f > 0f: .word 0x80000000 > > This extended form of ldr takes 4 bytes, and it doesn't require nor > ensure the target word to be aligned to a 4-byte boundary. It just so > happens that, if it's not aligned, the value loaded into the register is > a rotated version of the word containing the misaligned address. > > I'm not sure it would be appropriate for us to reject potentially > misaligned words: there might be (obfuscated) code intended to detect > and behave differently depending on whether it ends up at an even or odd > half-word. > > However, I think it would be nice for us to at least warn that the code > might behave differently depending on the actual alignment it gets. I'm > thinking something as simple as tracking the max natural alignment used > in each segment, and warning of potental linker-induced behavior changes > if that alignment is not recorded for the segment. > > Tracking symbols with their natural alignments, and maybe even > references to them that expect a certain alignment, might be pushing too > far, on the one hand, and still missing relevant cases of separate > compilation or complex address computations on the other. > > Is this something we might want to pursue, so as to warn even for e.g.: > > .text > .word 0 > > but limited to once per segment? > > Or should we track and warn about PC-relative addressing requirements, > so as to warn about segments containing PC-relative addressing (in > whatever forms) whose expected alignment exceeds the section's? (this > could miss e.g. setting a register to PC + offset, and then loading a > word at the address stored in the register) > > A combination of these? > > Thoughts? > Hmm, interesting issue. Given that we have .word and .4byte for all arm targets, where .4byte is intended to support deliberately unspecified alignment, I think it would be quite reasonable to warn whenever .word appears in a section with less than 4-byte alignment. > > Here's the patchlet that covers only the PCrel-load-to-low-reg case: > > --- gas/config/tc-arm.c 2020-01-28 12:50:34.000000000 +0100 > +++ gas/config/tc-arm.c 2020-02-18 00:13:11.486184639 +0100 > @@ -28755,6 +28755,9 @@ > (((unsigned long) fixP->fx_frag->fr_address > + (unsigned long) fixP->fx_where) & ~3) > + (unsigned long) value); > + else if (get_recorded_alignment (seg) < 2) > + as_warn_where (fixP->fx_file, fixP->fx_line, > + _("segment does not ensure enough alignment for target word")); > > if (value & ~0x3fc) > as_bad_where (fixP->fx_file, fixP->fx_line, > > This is OK. R.