Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel : 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,

Am 31.03.2024 um 21:35 schrieb Florian Klämpfl via fpc-devel : > Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel : > > 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.

> Am 31.03.2024 um 21:35 schrieb Florian Klämpfl via fpc-devel > : > > > >> Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel >> : >> >> 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 https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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 >> : >> >> >> >>> Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel >>> : >>> >>> 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 > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel _______________________________________________ fpc-devel maillist https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Am 31.03.2024 um 21:58 schrieb Michael Ring via fpc-devel : 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

> Am 31.03.2024 um 21:58 schrieb Michael Ring via fpc-devel > : > > 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 > My last commit should fix it. _______________________________________________ fpc-devel maillist https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Works, thank you! Michael Am 31.03.24 um 22:18 schrieb Florian Klämpfl via fpc-devel: > > >> Am 31.03.2024 um 21:58 schrieb Michael Ring via fpc-devel >> : >> >> 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 >> > > My last commit should fix it. > > > _______________________________________________ > fpc-devel maillist > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel _______________________________________________ fpc-devel maillist https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel