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

["Фёдар Стрыжнёў" <fedor_qd@mail.ru>]

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.
>