gcc -O1 causes Memory fault

[jserv]

F9 Microkernel is known to crash if being built with gcc -O1 (or higher order):

--------------------------------------
F9 microkernel is ready!
Press '?' to print KDB menu
Memory fault
-------KTABLES------

KT: fpage_table
bitmap:10000000, data:200013e4, num: 256 size: 16
    0: XXXXXXXXXXXXXXX--X---XX-X---XX-X--X--------X-XX---XX---------XX-
   64: --XXX-XXX--X---X--X-X-------XXXXX-------XXXX----XX-XXXXXX---X-XX
  128: --------X---XXXX--X-------------X-------X---XXXX--X-----X-------
  192: -X---X-XX---XXXXX--------X------X---XXXXXXX--XXX---------XXXXX-X

commit 551b9f0 disables optimization as workaround.

[arcbbb]

it seems after optimization "-O1" the variables kip and __kip_extra are rearranged,
and F9 assumes __kip_extra must be located after kip while doing get_free_base(kip)

kip_mem_desc_t *desc = ((void *) kip_ptr) +                             
                        kip_ptr->memory_info.s.memory_desc_ptr;          

we can see this in
arm-none-eabi-nm build/discoveryf4/f9.elf|grep kip|sort
before "-O1"

20000400 D kip
20000400 D kip_start
20000500 D __kip_extra
20000600 D kip_end
200006d4 D kip_extra
20001420 b kip_fpage
20001424 b kip_extra_fpage

after "-O1"

20000400 D __kip_extra
20000400 D kip_start
20000480 D kip
20000600 D kip_end
200006c8 D kip_extra
20001400 b kip_fpage
20001404 b kip_extra_fpage

[jserv]

@arcbbb Using gcc flag -fno-toplevel-reorder can avoid top-level function reordering.
However, it doesn't really change the situation.

[arcbbb]

Fantastic compiler flag! learned a great lesson.
So the next challenge is Usage Fault... I'll try hard on it!

[jserv]

@arcbbb Yes, gcc consists of the collection of the magic.
@kito-cheng is our compiler hacker, and you can consult him

[arcbbb]

It seems like inline assembly in L4_Ipc doesn't work after gcc optimization.
The high_mrs stored in [sp, #4] is overrided by stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp},
thus ldr.w ip, [sp, #4] loads the wrong high_mrs value.
I am thinking about the solution to this.

volatile int __USER_TEXT L4_Ipc(                                                
                l4_thread_t to, l4_thread_t from,                               
                uint32_t timeouts, uint32_t *high_mrs)                          
{                                                                               
 800c010:       b084            sub     sp, #16                                 
 800c012:       9301            str     r3, [sp, #4]                            
 800c014:       e92d 0ff0       stmdb   sp!, {r4, r5, r6, r7, r8, r9, sl, fp}   
 800c018:       f8dd c004       ldr.w   ip, [sp, #4]                            
 800c01c:       e89c 0ff0       ldmia.w ip, {r4, r5, r6, r7, r8, r9, sl, fp}       
 800c020:       df06            svc     6
 800c022:       e8bd 0ff0       ldmia.w sp!, {r4, r5, r6, r7, r8, r9, sl, fp}
 800c026:       9003            str     r0, [sp, #12]

original inline assembly:

        __asm__ __volatile__ ("push {r4-r11}\n"                                
                               "ldr r12, %1\n"                                  
                               "ldm r12, {r4-r11}\n"                            
                               "svc #6\n"                                       
                               "pop {r4-r11}\n"                                 
                               "str r0, %[output]\n"                            
                               : [output] "=m" (result)                         
                               : "m"(high_mrs));            

[arcbbb]

gcc -O1 flag seems ok after this patch.
WIP: https://github.com/arcbbb/f9-kernel/tree/fix-gcc_opt

[jserv]

Verified and merged.

Thanks!