[fpc-devel] Unaligned access on Cortex-M0 in Initialization code

[Michael Ring]

This is what I see (guess the same thing):

New Compiler:

FPC_INITIALIZE:
.Lc3882:
# path: /Users/ring/devel/fpc/rtl/inc/
# file: rtti.inc
# indx: 19
.Ll10741:
         push    {r4,r5,r14}
...

         ldr     r0,[r0, r1]
         mov     r15,r0
.La5:
         .long   .Lj13323

Old Compiler (2 years old):

FPC_INITIALIZE:
.Lc3594:
# path: /Users/ring/devel/freepascal-sources/rtl/inc/
# file: rtti.inc
# indx: 19
.Ll10488:
         push    {r4,r5,r14}
...

         mov     r15,r0
*        .balign 4*
.La5:
         .long   .Lj12924

Am 31.03.24 um 21:50 schrieb Florian Klämpfl via fpc-devel:
>
>
>> Am 31.03.2024 um 21:35 schrieb Florian Klämpfl via fpc-devel 
>> <fpc-devel at lists.freepascal.org>:
>>
>>
>>
>>> Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel 
>>> <fpc-devel at lists.freepascal.org>:
>>>
>>> Hi,
>>>
>>> it has been a while since I have been deep,deep down in the rabbit 
>>> hole of Cortex Assembly, so please forgive me if I am overlooking 
>>> something...
>>>
>>> I have an application for Raspberry Pico (target embedded) and it 
>>> fails during initialization as soon as I add a unit that includes an 
>>> object and I reference the object in my code...
>>>
>>> In that case fpc_initialize (for rtti?) is called and I cannot find 
>>> source code for fpc_initialize
>>>
>>> In the debugger I see that R0 is $1000177E and R1 is $28 This is in 
>>> the flash area, so far, so good but $1000177E is obviously not word 
>>> alligned, it is halfword aligned so this then triggers 
>>> _HardFault_Handler.
>>>
>>> 10001778 4648                     ldr             r0, [pc, #280] ; 
>>> (0x10001894 <fpc_initialize+316>)
>>> 1000177A 4058                     ldr             r0, [r0, r1] ; 
>>> Crash Boom Bang !!!!!
>>>
>>> Looking at the map file the address is within fpc_initialize, but as 
>>> I cannot find the proper source I am a bit lost...
>>>
>>> .text.n_fpc_initialize
>>>                0x0000000010001758      0x144 
>>> /Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o
>>>                0x0000000010001758                fpc_initialize
>>>                0x0000000010001758                FPC_INITIALIZE
>>> .text.n_fpc_finalize
>>>                0x000000001000189c      0x164 
>>> /Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o
>>>
>>> Any help appreciated,
>>
>> Can you post some more context? fpc_initalize is not that big so it 
>> should be possible to identify where this comes from.
>
> Ok, I think I found it, it is one for Gareth:
>
> var
>
>   i : longint;
>
> begin
>
>   case i of
>
>     1: writeln(1);
>
>     2: writeln(2);
>
>     3: writeln(2);
>
>     4: writeln(2);
>
>     5: writeln(2);
>
>   end;
>
> end.
>
>
> ppcarm -Cparmv6m -al -O2 t.pp -Tlinux -Oonopeephole
>
>
> results in:
> ...
> subr1,#1
> lslr1,r1,#2
> ldrr0,.Lj11
> ldrr0,[r0, r1]
> movr15,r0
> .balign 4
> .La1:
> .long.Lj4
> .long.Lj5
> .long.Lj6
> .long.Lj7
> .long.Lj8
> …
>
> The peephole removes the alignment before case jump tables: if no 
> -Oonopeephole is passed, the .balign 4 is gone.
>
>
> _______________________________________________
> fpc-devel maillist  -fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20240331/9731a92c/attachment-0001.htm>