From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp42.i.mail.ru (smtp42.i.mail.ru [94.100.177.102]) by sourceware.org (Postfix) with ESMTPS id 0054A3858C60 for ; Fri, 21 Jan 2022 14:16:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0054A3858C60 Received: by smtp42.i.mail.ru with esmtpa (envelope-from ) id 1nAuim-0002Hg-UB; Fri, 21 Jan 2022 17:16:57 +0300 Date: Fri, 21 Jan 2022 17:17:01 +0300 From: =?Windows-1251?Q?=D4=B8=E4=E0=F0_=D1=F2=F0=FB=E6=ED=B8=A2?=(Fiodar Stryzhniou) To: Richard Earnshaw Cc: gcc-help@gcc.gnu.org Subject: Re: Symbian: unalighned relocations for pointers-to-members Message-Id: <20220121171701.7f1d9228113d2b9b0b4aee19@mail.ru> In-Reply-To: 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> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9AA78FDF62ECAE61F574C814AB3F23F4AA01FB0D4144D4AE0182A05F53808504035D9107139F5C10C1C9CE1790FBEFA003E5282EC322BACD5B36A50004C8ABADB X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE728F774C865CF4B07EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637B23888C9749F3CAC8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8669A53C8F1B9711715B0D80120B9F3A06F9789CCF6C18C3F8528715B7D10C86878DA827A17800CE767883B903EA3BAEA9FA2833FD35BB23D9E625A9149C048EE33AC447995A7AD18C26CFBAC0749D213D2E47CDBA5A96583BD4B6F7A4D31EC0BC014FD901B82EE079FA2833FD35BB23D27C277FBC8AE2E8B974A882099E279BDA471835C12D1D977C4224003CC836476EB9C4185024447017B076A6E789B0E975F5C1EE8F4F765FCB4DCEC625E10BF493AA81AA40904B5D9CF19DD082D7633A078D18283394535A93AA81AA40904B5D98AA50765F7900637835B38F170B8AB18D81D268191BDAD3D698AB9A7B718F8C4D1B931868CE1C5781A620F70A64A45A98AA50765F79006372E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89FD2A95C73FD1EFF4557739F23D657EF2BB5C8C57E37DE458BEDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A5ED4954380E3961825DDEC5ABF867E9F90BCBF3A2E604D831D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA752CE3587E4385123B410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34E69981C39E7B068A726A221DF03311F4A1CE39F9957FDB5908B8761B54ACC962963035AB05529E4E1D7E09C32AA3244C2CC9C5DDF584735E3B4E3299A49680C3795D98D676DD64D0729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojeO2NaHb0kQsTXdzlgT68Mg== X-Mailru-Sender: B5420D632883B294CF6673AD81AF0FB65D2AF0DC9F2D6FF4E8EDD4E6B791ADFCE2527C969975515C2B4E3A9B39D17ED8FB559BB5D741EB9638645ACA06CB6E346F53C80213D1719C67EA787935ED9F1B X-Mras: Ok X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham 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 14:17:01 -0000 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. >