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