Author Topic: FluffOS on ARM  (Read 2456 times)

Offline nfa

  • Acquaintance
  • *
  • Posts: 28
    • View Profile
FluffOS on ARM
« on: February 09, 2012, 10:12:12 am »
Anyone running it on an ARM architecture?

I'm getting really weird segfaults when it tries to load the simul_efun object.

A -ggdb compiled driver gives this:

Code: [Select]
Starting program: /home/mud/sys/crash_feb12/bin/driver config.fr
[Thread debugging using libthread_db enabled]
using config file: config.fr
Initializing internal tables....
----------------------------------------------------------------------------
fr (FluffOS v2.23) starting up on Linux - Thu Feb  9 16:56:30 2012


Connected to address server on localhost port 6364
]simul_efun loaded
preload_table::create()
preload_table::create()

Program received signal SIGSEGV, Segmentation fault.
0x00027174 in int_free_svalue (v=0x244328) at interpret.c:481
481         if (!(--v->u.refed->ref)) {
(gdb) bt
#0  0x00027174 in int_free_svalue (v=0x244328) at interpret.c:481
#1  0x000312d0 in eval_instruction (p=0x244fd9 "\022") at interpret.c:2903
#2  0x00035ecc in call___INIT (ob=0x240398) at interpret.c:4433
#3  0x00046fb8 in call_create (ob=0x240398, num_arg=0) at object.c:2032
#4  0x0003b0d4 in int_load_object (lname=0xbee94ea8 "secure/master_fr") at simulate.c:520
#5  0x0003af10 in int_load_object (lname=0xbee9524c "secure/master_fr") at simulate.c:488
#6  0x000a1ce8 in init_master () at master.c:57
#7  0x0002429c in main (argc=2, argv=0xbee977c4) at main.c:322
(gdb)


A -ggdb and debug build of the driver gives this (no backtrace since it aborts via fatal()):
Code: [Select]
(gdb) run config.fr
Starting program: /home/mud/sys/crash_feb12/bin/driver-debug_gdb config.fr
[Thread debugging using libthread_db enabled]
using config file: config.fr
Initializing internal tables....
----------------------------------------------------------------------------
fr (FluffOS v2.23) starting up on Linux - Thu Feb  9 16:57:42 2012


Connected to address server on localhost port 6364
******** FATAL ERROR: Illegal variable access 325(13).

FluffOS driver attempting to exit gracefully.
(current object was /secure/simul_efun)
Recent instruction trace:
3220ff:   2          efun2                     (0)
322103: 120          efun120                   (2)
322104:  69          global_lvalue             (1)
--- trace ---
'  #global_init#' in '/ secure/simul_efun.c' ('/   secure/simul_efun') /secure/simul_efun/groups_newbies.i:14
arguments were ()
--- end trace ---
crash() in master called successfully.  Aborting.

Program received signal SIGABRT, Aborted.
0x402b9c88 in raise () from /lib/libc.so.6


Relevant code at line 14 in groups_newbies.i is just:
Code: [Select]
int world_war_flag = 0;Basically it seems to choke on everything with an assignment in the object. If I comment those out or just set them to int world_war_flag; I'll just run into same error but further ahead.


And even more weird is that if I run it outside of gdb it segfaults after the simul_efun object is loaded. There is no consistency to the errors. I compile it with additional flags :
Code: [Select]
-march=armv5t -mfloat-abi=softSame error without those flags though.

However:
Code: [Select]
   lqqinterpret.cqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
  >x481         if (!(--v->u.refed->ref)) {                                                                                                                   x
   x482           switch (v->type) {                                                                                                                          x
   x483           case T_OBJECT:                                                                                                                              x
   x484             dealloc_object(v->u.ob, "free_svalue");                                                                                                   x
   x485             break;                                                                                                                                    x
   x486           case T_CLASS:                                                                                                                               x
   x487             dealloc_class(v->u.arr);                                                                                                                  x
   x488             break;                                                                                                                                    x
   x489           case T_ARRAY:                                                                                                                               x
   x490             if (v->u.arr != &the_null_array)                                                                                                          x
   x491               dealloc_array(v->u.arr);                                                                                                                x
   x492             break;                                                                                                                                    x
   x493     #ifndef NO_BUFFER_TYPE                                                                                                                            x
   x494           case T_BUFFER:                                                                                                                              x
   x495             if (v->u.buf != &null_buf)                                                                                                                x
   x496               FREE((char *)v->u.buf);                                                                                                                 x
   x497             break;                                                                                                                                    x
   lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
   x0x2716c <int_free_svalue+512>   ldr    r3, [r11, #-16]                                                                                                    x
   x0x27170 <int_free_svalue+516>   ldr    r3, [r3, #8]                                                                                                       x
  >x0x27174 <int_free_svalue+520>   ldrh   r2, [r3]                                                                                                           x
   x0x27178 <int_free_svalue+524>   sub    r2, r2, #1                                                                                                         x
   x0x2717c <int_free_svalue+528>   lsl    r2, r2, #16                                                                                                        x
   x0x27180 <int_free_svalue+532>   lsr    r2, r2, #16                                                                                                        x
   x0x27184 <int_free_svalue+536>   strh   r2, [r3]                                                                                                           x
   x0x27188 <int_free_svalue+540>   ldrh   r3, [r3]                                                                                                           x
   x0x2718c <int_free_svalue+544>   cmp    r3, #0                                                                                                             x
   x0x27190 <int_free_svalue+548>   bne    0x272ec <int_free_svalue+896>                                                                                      x
   x0x27194 <int_free_svalue+552>   ldr    r3, [r11, #-16]                                                                                                    x
   x0x27198 <int_free_svalue+556>   ldrh   r3, [r3]                                                                                                           x
   x0x2719c <int_free_svalue+560>   lsl    r3, r3, #16                                                                                                        x
   x0x271a0 <int_free_svalue+564>   asr    r3, r3, #16                                                                                                        x
   x0x271a4 <int_free_svalue+568>   cmp    r3, #64 ; 0x40                                                                                                     x
   x0x271a8 <int_free_svalue+572>   beq    0x2727c <int_free_svalue+784>                                                                                      x
   x0x271ac <int_free_svalue+576>   cmp    r3, #64 ; 0x40                                                                                                     x
   mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
multi-thre Thread 0x4015b In: int_free_svalue                                                                                           Line: 481  PC: 0x27174
(gdb)


It segfaults on the ldrh instruction which from googling seem to be ARM specific.

I should also mention that there's no problem on an x86.

Offline Raudhrskal

  • BFF
  • ***
  • Posts: 214
  • The MUD community needs YOUR help!
    • View Profile
Re: FluffOS on ARM
« Reply #1 on: February 09, 2012, 03:40:38 pm »
Probably another unaligned access. Look at the value of the memory address it tries to access to in the ldrh call (if ARM asm is anything like Intel asm, it'll be in register r3), and make sure it's divisible by 4 EDIT: apparently by 2, ldrh is "load halfword to register". And yes, the stuff in square brackets, in this case register r3, contains the memory address.
There was some problem on sparc64 recently that also was caused by misalignment.
x86 silently (at cost of huge speed loss) supports unaligned access. Most other architectures raise a CPU exception.

... and, erm, apologies to everyone. I should shut up.
« Last Edit: February 09, 2012, 03:47:40 pm by Raudhrskal »
I think, therefore i may be wrong.
Please note that if you met a Raudhrskal in a place that's not related to muds, it wasn't me. *sigh*... back when I started there was zero hits on google for that name...

Offline nfa

  • Acquaintance
  • *
  • Posts: 28
    • View Profile
Re: FluffOS on ARM
« Reply #2 on: February 09, 2012, 04:14:39 pm »
Doesn't seem that way:
Code: [Select]
(gdb) info registers r3
r3             0xf000319        251659033

Offline nfa

  • Acquaintance
  • *
  • Posts: 28
    • View Profile
Re: FluffOS on ARM
« Reply #3 on: February 10, 2012, 09:13:47 am »
Got it running. Changed max variables down to 256 so it wouldn't use the unsigned short pointer for program instructions. Had to prune some variables.

Seems >256 max global variables don't work well on ARM.