public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: "Фёдар Стрыжнёў (Fiodar Stryzhniou)" <fedor_qd@mail.ru>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Symbian: unalighned relocations for pointers-to-members
Date: Tue, 18 Jan 2022 10:14:17 +0000	[thread overview]
Message-ID: <c0562e18-1f47-9403-fab8-ab430dd4f7d9@foss.arm.com> (raw)
In-Reply-To: <20220116145241.ff761ae396f6b5cef3d53cd0@mail.ru>

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


> Output:
> arm-none-symbianelf-gcc -c -marm main.cpp
> arm-none-symbianelf-readelf -a main.o
> Relocation section '.rel.rodata' at offset 0x9e0 contains 8 entries:
>  Offset     Info    Type            Sym.Value  Sym. Name
> 00000058  00000f02 R_ARM_ABS32       00000000   .rodata
> 00000060  00000f02 R_ARM_ABS32       00000000   .rodata
> 00000064  00001a02 R_ARM_ABS32       00000000   _ZN5Items17isRune[...]
> 0000006c  00001b02 R_ARM_ABS32       00000000   _ZN5Items18putRun[...]
> 00000081  00000f02 R_ARM_ABS32       00000000   .rodata
>       ^^
> 00000089  00000f02 R_ARM_ABS32       00000000   .rodata
> 0000008d  00001a02 R_ARM_ABS32       00000000   _ZN5Items17isRune[...]
> 00000095  00001b02 R_ARM_ABS32       00000000   _ZN5Items18putRun[...]
>>
>> On 29/12/2021 11:04, Фёдар Стрыжнёў (Fiodar Stryzhniou) via Gcc-help wrote:
>>> On Mon, 20 Dec 2021 15:37:26 +0000
>>> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote:
>>>
>>>> On 16/12/2021 00:39, Фёдар Стрыжнёў (Fiodar Stryzhniou) via Gcc-help wrote:
>>>>> Hello. I maintain ScummVM port for Symbian Series 60v3. ScummVM is a complete rewrite of hundreds old games' executables and is not an emulator. It's free and opensource.
>>>>>
>>>>> Last year, when I prepared a version 2.2.0 in the release, it was faced with the fact that when the Ultima engine is turned on in the executable file (supports Ultima 1, 4, 6, 8), it does not start. Ultima 4 & 6 support disabling allowed SCUMMVM. In the spring of this year, after some changes in the source code Ultima, the elf2e32 utility has begun to complete the work with the error "Line 427". To clarify the causes of the error, a rebeling of the code responsible for the support of Ultima 4 & 6 was carried out.
>>>>> The rebel passed as follows:
>>>>> 1. Removed ultima.lib (Static Library)
>>>>> 2. Left the entry point, deleted all other files associated with Ultima 4/6 from the project assembly
>>>>> 3. Collected ultima.lib, then collected scummvm.exe
>>>>> 4. Added files to the project and continued to collect until the error did not jump out.
>>>>>
>>>>> I have done these steps first for Ultima 4, then - 6. In both cases, the reason was pointer-to-member array declaration.
>>>>> Ultima 4 - https://github.com/scummvm/scummvm/blob/master/engines/ultima/ultima4/game/item.cpp#L49
>>>>> Ultima 6 - https://github.com/scummvm/scummvm/blob/master/engines/ultima/nuvie/usecode/u6_object_types.h#L28
>>>>>
>>>>> elf2e32 creates E32 aka EPOC32 aka Symbian exe and dlls from elf.
>>>>>
>>>>> Analysis of the elf2e32 source code indicated the reason - when checking the created file, unaligned relocations were found. After modifying the source code, the elf2e32 was printed unaligned relocations. I redirect to file "readelf -a <name of elf>". I find several random Elf32_Rel r_offset from elf2e32 in readelf output. GCC 5.4.0 and 11.2.0 give same result.
>>>>>
>>>>>
>>>>
>>>> I can't tell from this what the issue might be.  To stand any chance of
>>>> proceeding further, I think we're going to need a simple,
>>>> self-contained, testcase that can demonstrate the problem.
>>>>
>>>> I don't think I've seen a question about SymbianOS support in over 5
>>>> years, now, possibly longer.  Given that SymbianOS itself was
>>>> discontinued back around 2013 (8 years ago now), the GCC port has
>>>> declined to the point where I suspect it's likely to get deprecated
>>>> soon, due to lack of maintenance.
>>>>
>>>> R.
>>>
>>> I made very small testcase in main.cpp. Attachment contains Carbide С++
>>> project files too if needed.
>>>
>>> Console output taken from Carbide C++:
>>> Using built-in specs.
>>> COLLECT_GCC=arm-none-symbianelf-gcc
>>> Target: arm-none-symbianelf
>>> Configured with: ../gcc-11.2.0/./configure --target=arm-none-symbianelf
>>> --prefix=/usr/local/gcc-11.2.0 --without-headers --enable-languages=c,c+
>>> +,lto --enable-poison-system-directories --enable-lto --with-newlib
>>> --enable-long-long --with-libiconv-prefix=/usr/local --with-dwarf2
>>> --enable-interwork --enable-tls --enable-multilib
>>> --disable-hosted-libstdcxx --disable-libstdcxx-pch
>>> --disable-option-checking --disable-threads --disable-nls
>>> --disable-win32-registry --disable-libssp --disable-shared
>>> --enable-wchar_t --enable-extra-sgxxlite-multilibs --enable-c99
>>> --with-static-standard-libraries Thread model: single Supported LTO
>>> compression algorithms: zlib gcc version 11.2.0 (GCC)
>>> COLLECT_GCC_OPTIONS='-g3' '-gdwarf-2' '-fexceptions' '-Wall'
>>> '-Wno-unknown-pragmas'  '-mapcs-frame' '-mthumb-interwork' '-pipe'
>>> '-nostdinc' '-c' '-Wno-multichar' '-Wno-unused' '-Wformat=0' '-v'
>>> '-marm' '-mfloat-abi=soft' '-D' '__MARM_INTERWORK__' '-MD' '-D'
>>> '_DEBUG' '-D' '_UNICODE' '-D' '__GCCE__' '-D' '__SYMBIAN32__' '-D'
>>> '__S60_50__' '-D' '__S60_3X__' '-D' '__SERIES60_3X__' '-D' '__GCCE__'
>>> '-D' '__EPOC32__' '-D' '__MARM__' '-D' '__EABI__' '-D' '__MARM_ARMV5__'
>>> '-D' '__EXE__' '-D' '__SUPPORT_CPP_EXCEPTIONS__' '-D' '__MARM_ARMV5__'
>>> '-D'
>>> '__PRODUCT_INCLUDE__="/Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include/variant/Symbian_OS.hrh"'
>>> '-Wno-ctor-dtor-privacy' '-fpermissive' '-std=c++14' '-include'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/INCLUDE/GCCE/gcce.h' '-I'
>>> '/Symbian/Projects/unalighned_reloc_report/src' '-I'
>>> '/Symbian/Projects/unalighned_reloc_report/inc' '-I'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include' '-I'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include/variant' '-I'
>>> 'd:/mingw/msys/1.0/local/gcc-11.2.0/lib/gcc/arm-none-symbianelf/11.2.0/include'
>>> '-o'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/main.o'
>>> '-mlibarch=armv5t' '-march=armv5t' '-dumpdir'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/'
>>> d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../libexec/gcc/arm-none-symbianelf/11.2.0/cc1plus.exe
>>> -quiet -nostdinc -v -I /Symbian/Projects/unalighned_reloc_report/src
>>> -I /Symbian/Projects/unalighned_reloc_report/inc
>>> -I /Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include
>>> -I /Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include/variant -I
>>> d:/mingw/msys/1.0/local/gcc-11.2.0/lib/gcc/arm-none-symbianelf/11.2.0/include
>>> -iprefix d:\mingw\msys\1.0\local\gcc-11.2.0\bin
>>> \../lib/gcc/arm-none-symbianelf/11.2.0/
>>> -MD /Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/main.d
>>> -MQ /Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/main.o
>>> -dD -D__USES_INITFINI__ -D __MARM_INTERWORK__ -D _DEBUG -D _UNICODE -D
>>> __GCCE__ -D __SYMBIAN32__ -D __S60_50__ -D __S60_3X__ -D
>>> __SERIES60_3X__ -D __GCCE__ -D __EPOC32__ -D __MARM__ -D __EABI__ -D
>>> __MARM_ARMV5__ -D __EXE__ -D __SUPPORT_CPP_EXCEPTIONS__ -D
>>> __MARM_ARMV5__ -D
>>> __PRODUCT_INCLUDE__="/Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include/variant/Symbian_OS.hrh"
>>> -include /Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/INCLUDE/GCCE/gcce.h /Symbian/Projects/unalighned_reloc_report/src/main.cpp
>>> -fno-builtin -fvisibility=hidden -fno-short-enums -fshort-wchar -quiet
>>> -dumpdir /Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/
>>> -dumpbase main.cpp -dumpbase-ext .cpp -mapcs-frame -mthumb-interwork
>>> -marm -mfloat-abi=soft -mlibarch=armv5t -march=armv5t -g3 -gdwarf-2
>>> -Wall -Wno-unknown-pragmas -Wno-multichar -Wno-unused -Wformat=0
>>> -Wno-ctor-dtor-privacy -std=c++14 -version -fexceptions -fpermissive
>>> -fno-builtin -fvisibility=hidden -fno-short-enums -fshort-wchar -o - |
>>> d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../lib/gcc/arm-none-symbianelf/11.2.0/../../../../arm-none-symbianelf/bin/as.exe
>>> -march=armv5t -mapcs-frame -mfpu=vfp -mthumb-interwork -mfloat-abi=soft
>>> -meabi=5
>>> -o /Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/main.o
>>> GNU C++14 (GCC) version 11.2.0 (arm-none-symbianelf) compiled by GNU C
>>> version 6.3.0, GMP version 6.1.0, MPFR version 4.1.0, MPC version
>>> 1.2.1, isl version isl-0.16.1-GMP
>>>
>>> GGC heuristics: --param ggc-min-expand=100 --param
>>> ggc-min-heapsize=131072
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>>   /Symbian/Projects/unalighned_reloc_report/src
>>>   /Symbian/Projects/unalighned_reloc_report/inc
>>>   /Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include
>>>   /Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include/variant
>>>   d:/mingw/msys/1.0/local/gcc-11.2.0/lib/gcc/arm-none-symbianelf/11.2.0/include
>>> End of search list.
>>> GNU C++14 (GCC) version 11.2.0 (arm-none-symbianelf)
>>> 	compiled by GNU C version 6.3.0, GMP version 6.1.0, MPFR
>>> version 4.1.0, MPC version 1.2.1, isl version isl-0.16.1-GMP
>>>
>>> GGC heuristics: --param ggc-min-expand=100 --param
>>> ggc-min-heapsize=131072 Compiler executable checksum:
>>> 7bd26c26f5e3795062462f9efc696d4f
>>> COMPILER_PATH=d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../libexec/gcc/arm-none-symbianelf/11.2.0/;d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../libexec/gcc/;d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../lib/gcc/arm-none-symbianelf/11.2.0/../../../../arm-none-symbianelf/bin/
>>> LIBRARY_PATH=d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../lib/gcc/arm-none-symbianelf/11.2.0/;d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../lib/gcc/;d:/mingw/msys/1.0/local/gcc-11.2.0/bin/../lib/gcc/arm-none-symbianelf/11.2.0/../../../../arm-none-symbianelf/lib/
>>> COLLECT_GCC_OPTIONS='-g3' '-gdwarf-2' '-fexceptions' '-Wall'
>>> '-Wno-unknown-pragmas'  '-mapcs-frame' '-mthumb-interwork' '-pipe'
>>> '-nostdinc' '-c' '-Wno-multichar' '-Wno-unused' '-Wformat=0' '-v'
>>> '-marm' '-mfloat-abi=soft' '-D' '__MARM_INTERWORK__' '-MD' '-D'
>>> '_DEBUG' '-D' '_UNICODE' '-D' '__GCCE__' '-D' '__SYMBIAN32__' '-D'
>>> '__S60_50__' '-D' '__S60_3X__' '-D' '__SERIES60_3X__' '-D' '__GCCE__'
>>> '-D' '__EPOC32__' '-D' '__MARM__' '-D' '__EABI__' '-D' '__MARM_ARMV5__'
>>> '-D' '__EXE__' '-D' '__SUPPORT_CPP_EXCEPTIONS__' '-D' '__MARM_ARMV5__'
>>> '-D'
>>> '__PRODUCT_INCLUDE__="/Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include/variant/Symbian_OS.hrh"'
>>> '-Wno-ctor-dtor-privacy' '-fpermissive' '-std=c++14' '-include'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/INCLUDE/GCCE/gcce.h' '-I'
>>> '/Symbian/Projects/unalighned_reloc_report/src' '-I'
>>> '/Symbian/Projects/unalighned_reloc_report/inc' '-I'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include' '-I'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/epoc32/include/variant' '-I'
>>> 'd:/mingw/msys/1.0/local/gcc-11.2.0/lib/gcc/arm-none-symbianelf/11.2.0/include'
>>> '-o'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/main.o'
>>> '-mlibarch=armv5t' '-march=armv5t' '-dumpdir'
>>> '/Symbian/S60_5th_Edition_SDK_v1.0/EPOC32/BUILD/Symbian/Projects/unalighned_reloc_report/epoc/UNALIGHNED_RELOC_REPORT/GCCE/udeb/main.'
>>> ‘files copied:         1. line 437 elf2e32 : Error: E1066: Image failed
>>> validation make[1]: *** [\Symbian\S60_5th_Edition_SDK_v1.0\epoc32
>>> \release\gcce\udeb\unalighned_reloc_report.exe] Error 1 make: ***
>>> [TARGETUNALIGHNED_RELOC_REPORT] Error 2
>>>
>>> -----
>>> Фёдар Стрыжнёў(Fiodar Stryzhniou) <fedor_qd@mail.ru>
>>>
> 
> 
> ----- 
> Фёдар Стрыжнёў(Fiodar Stryzhniou) <fedor_qd@mail.ru>
> 


  reply	other threads:[~2022-01-18 10:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-16  0:39 Фёдар Стрыжнёў
2021-12-19  9:35 ` Фёдар Стрыжнёў
2021-12-20 15:37 ` Richard Earnshaw
2021-12-20 19:30   ` Фёдар Стрыжнёў
2021-12-21  0:00     ` Segher Boessenkool
2021-12-21 14:01       ` Фёдар Стрыжнёў
2021-12-21 14:13         ` Jonathan Wakely
2021-12-21 15:17           ` Фёдар Стрыжнёў
2021-12-21 17:05             ` Jonathan Wakely
2021-12-29 11:04   ` Фёдар Стрыжнёў
2022-01-04 13:01     ` Richard Earnshaw
2022-01-16 11:52       ` Фёдар Стрыжнёў
2022-01-18 10:14         ` Richard Earnshaw [this message]
2022-01-21 14:17           ` Фёдар Стрыжнёў
2022-01-21 15:08             ` Richard Earnshaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0562e18-1f47-9403-fab8-ab430dd4f7d9@foss.arm.com \
    --to=richard.earnshaw@foss.arm.com \
    --cc=fedor_qd@mail.ru \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).