From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id ED16E3858C60 for ; Fri, 21 Jan 2022 15:08:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED16E3858C60 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 5FFBD101E; Fri, 21 Jan 2022 07:08:52 -0800 (PST) Received: from [10.57.36.197] (unknown [10.57.36.197]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D89D93F774; Fri, 21 Jan 2022 07:08:51 -0800 (PST) Subject: Re: Symbian: unalighned relocations for pointers-to-members To: =?UTF-8?B?0KTRkdC00LDRgCDQodGC0YDRi9C20L3RkdGeIChGaW9kYXIgU3RyeXpobmlv?= =?UTF-8?Q?u=29?= Cc: gcc-help@gcc.gnu.org References: <20211216033947.6ba586c6ca664cb651cc4cb1@mail.ru> <8f38d61e-f5c2-b9a1-b2d3-3bf5ee5cb4a4@foss.arm.com> <20211229140449.2e727ee2fb05036de93d8ef8@mail.ru> <2fcf11b9-026f-b6e5-1641-025776e90d74@foss.arm.com> <20220116145241.ff761ae396f6b5cef3d53cd0@mail.ru> <20220121171701.7f1d9228113d2b9b0b4aee19@mail.ru> From: Richard Earnshaw Message-ID: <995c213b-400a-7056-e06a-fcc55ac4a48b@foss.arm.com> Date: Fri, 21 Jan 2022 15:08:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220121171701.7f1d9228113d2b9b0b4aee19@mail.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3489.7 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2022 15:08:56 -0000 The assembly output? Just compile with -S rather than -c and the compiler will output the assembler file rather than an object file. R. On 21/01/2022 14:17, Фёдар Стрыжнёў (Fiodar Stryzhniou) wrote: > How create such output? It's good to know such thing. > ----- > Фёдар Стрыжнёў(Fiodar Stryzhniou) > > On Tue, 18 Jan 2022 10:14:17 +0000 > Richard Earnshaw wrote: > >> [Sending a copy to the list as this was accidentally moved to private mail] >> >> On 16/01/2022 11:52, Фёдар Стрыжнёў (Fiodar Stryzhniou) wrote: >>> On Tue, 4 Jan 2022 13:01:14 +0000 >>> Richard Earnshaw wrote: >>> >>>> I've had a very quick look at this (I can only look at the compiler >>>> output as I do not have any of the other symbian-related tools). The >>>> only thing I can think of is that the problem is coming from the dwarf >>>> debug information. Can you check whether the problem still occurs if >>>> you add -g0 to the end of the list of compilation options (or remove all >>>> the -g... options from the compilation command). >>>> >>>> R. >>> >>> Sorry for long response. You mail was moved to spam by mail provider. >>> >>> Error remains. >>> >>> I made this file OS-independent. It can be linked and compiled by GCC. >>> I compile and use object dump. Found unaligned entry. Is it error? >>> >> >>> No, I think that's an exact consequence of having a packed data type. >> This is the relevant part of the assembly file (after passing through >> the demangler): >>> >>> .section .rodata >>> .align 2 >>> .LC0: >>> .ascii "the rune of Spirituality\000" >>> .align 2 >>> .LC1: >>> .ascii "spiritualityrune\000" >>> .align 2 >>> .LC2: >>> .ascii "the rune of Humility\000" >>> .align 2 >>> .LC3: >>> .ascii "humilityrune\000" >>> .align 2 >>> .type Items::ITEMS, %object >>> .size Items::ITEMS, 1394 >>> Items::ITEMS: >>> // RE: ITEMS[0] >>> .word .LC0 >>> .word 0 >>> .word .LC1 >>> .word Items::isRuneInInventory(int) >>> .word 0 >>> .word Items::putRuneInInventory(int) >>> .word 0 >>> .word 0 >>> .word 0 >>> .word 64 >>> .byte 0 >>> // RE: ITEMS[1] >>> .4byte .LC2 >>> .4byte 0 >>> .4byte .LC3 >>> .4byte Items::isRuneInInventory(int) >>> .4byte 0 >>> .4byte Items::putRuneInInventory(int) >>> .4byte 0 >>> .4byte 0 >>> .4byte 0 >>> .4byte 128 >>> .byte 0 >>> // RE: And some empty space. >>> .space 1312 >>> >>> Note that each entry in the ITEMS list is 41 bytes, so the second >>> element (and third and fourth, if initialized) has to be placed in an >>> unaligned location (because the structure has been packed). Note that >>> the .4byte directive is used by the compiler when it knows that the >>> element can be misaligned. >> >> Sorry, I meant to also say that your source code is using two ways of >> forcing packing: pragma pack and __attribute((packed)). If I remove >> both of those, then the output becomes >> >> Items::ITEMS: >> .word .LC0 >> .word 0 >> .word .LC1 >> .word Items::isRuneInInventory(int) >> .word 0 >> .word Items::putRuneInInventory(int) >> .word 0 >> .word 0 >> .word 0 >> .word 64 >> .byte 0 >> .space 3 >> .word .LC2 >> .word 0 >> .word .LC3 >> .word Items::isRuneInInventory(int) >> .word 0 >> .word Items::putRuneInInventory(int) >> .word 0 >> .word 0 >> .word 0 >> .word 128 >> .byte 0 >> .space 3 >> .space 1408 >> >> and we can see that the data is all now fully aligned. Leaving either >> one of the packed directives in place obviously leads to the object >> containing unaligned pointers, which leads to the unaligned relocations. >> >> AAELF (the ELF specification binding for Arm) states: >> >> Except as indicated in Table 4-10, Static Data relocations with >> non-standard size or processing all static data relocations have >> size 4, alignment 1 and [...]. >> >> R_ARM_ABS32 is not listed in Table 4-10, so can have any alignment. >> >> >> R. >>