Re: Symbian: unalighned relocations for pointers-to-members

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

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 <Richard.Earnshaw@foss.arm.com> 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@foss.arm.com> 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.
>>