How create such output? It's good to know such thing. ----- Фёдар Стрыжнёў(Fiodar Stryzhniou) On Tue, 18 Jan 2022 10:14:17 +0000 Richard Earnshaw <Richard.Earnshaw@xxxxxxxxxxxx> 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 <Richard.Earnshaw@xxxxxxxxxxxx> 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. >
