MacRuby issues

MacRuby Rakefile passes -fno-common twice when compiling ext directory.
May be clang can strip out duplicate entries before passing it to clang-cc.

~/Developer/MacRuby/ext/bigdecimal-> clang -I. -I../../.ext/include/universal-darwin9.0 -I..//.././include -I..//.././ext/bigdecimal -DRUBY_EXTCONF_H=\"extconf.h\" -fno-common -fno-common -pipe -O2 -g -Wall -Wno-parentheses -arch i386 -o bigdecimal.o -c bigdecimal.c
clang: warning: argument unused during compilation: '-Wno-parentheses'
clang-cc: for the -fno-common option: : may only occur zero or one times!

Also MacRuby currently doesn't compile in x86_64 arch when it uses miniruby to run
/usr/bin/make on the ext directory. It basically segments faults while
running this command. i386 runs this just fine so does gcc. may be it is bad code generation.

GC_DISABLE=1 ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb ext/extmk.rb --make="/usr/bin/make" --dest-dir="" --extout=".ext" --mflags="" --make-flags="" --extension --extstatic

MacRuby Rakefile passes -fno-common twice when compiling ext directory.
May be clang can strip out duplicate entries before passing it to
clang-cc.

Yes, that sounds like a bug. Please file a bugzilla:

~/Developer/MacRuby/ext/bigdecimal-> clang -I. -I../../.ext/include/
universal-darwin9.0 -I..//.././include -I..//.././ext/bigdecimal -
DRUBY_EXTCONF_H=\"extconf.h\" -fno-common -fno-common -pipe -O2 -g -
Wall -Wno-parentheses -arch i386 -o bigdecimal.o -c bigdecimal.c
clang: warning: argument unused during compilation: '-Wno-parentheses'
clang-cc: for the -fno-common option: : may only occur zero or one
times!

This should be enough description for the bugzilla, thanks!

Also MacRuby currently doesn't compile in x86_64 arch when it uses
miniruby to run
/usr/bin/make on the ext directory. It basically segments faults while
running this command. i386 runs this just fine so does gcc. may be
it is bad code generation.

GC_DISABLE=1 ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb
ext/extmk.rb --make="/usr/bin/make" --dest-dir="" --extout=".ext" --
mflags="" --make-flags="" --extension --extstatic

Have you tried with mainline? There was a recent bug fix in the optimizer that only manifested sometimes.

-Chris

Updated to revision 67745.
so basically I updated yesterday.

Try something after r67798

-Chris

Have you tried with mainline? There was a recent bug fix in the optimizer that only manifested sometimes.

-Chris

Updated to revision 67745.
so basically I updated yesterday.

Try something after r67798

well that took care of previous error. but now it is failing even earlier for both arch.
cpu just goes in race condition. I did make clean and updated both llvm and clang.

./miniruby -I. -I./lib -rrbconfig tool/compile_prelude.rb prelude.rb gem_prelude.rb prelude.c.new

on side note. can you tell me how to fix this warning. it is complaining about goto *(*reg_pc));

./vm.inc:2994:594: warning: incompatible integer to pointer conversion passing 'VALUE' (aka 'unsigned long'), expected 'void *'

   do { if (__dtrace_isenabled$macruby$insn__return$v1()) { rb_control_frame_t *cfp = (((reg_cfp))); rb_iseq_t *iseq = cfp- >iseq; if (iseq != ((void*)0) && ((cfp)->flag & (~(~0<<8))) != 0x51) { VALUE *seq = iseq->iseq; int pc = cfp->pc - iseq->iseq_encoded; { __asm__ volatile(".reference " "___dtrace_typedefs$macruby$v1"); __dtrace_probe$macruby$insn__return$v1$63686172202a$63686172202a$696e74((char *)rb_insn_name(seq[pc]), (char *)rb_sourcefile(), rb_sourceline()); __asm__ volatile(".reference " "___dtrace_stability$macruby$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0"); }; } } } while (0); ; goto *(*(reg_pc)); ;;;}}}
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  ^

I added that warning... it should go away with an explicit cast to
void*. I can remove it if this sort of thing is common, but it seems
like a good idea to require a pointer for indirect gotos. Also see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122.

-Eli

MacRuby Rakefile passes -fno-common twice when compiling ext directory.
May be clang can strip out duplicate entries before passing it to
clang-cc.

Fixed in r67863.

It basically segments faults

It would be wonderful if you could debug this and get down to the root problem and then report it.

MacRuby Rakefile passes -fno-common twice when compiling ext directory.
May be clang can strip out duplicate entries before passing it to
clang-cc.

Fixed in r67863.

This wasn't a show stopper since I just edited the Rakefile to remove the duplicate entry.

It basically segments faults

It would be wonderful if you could debug this and get down to the root problem and then report it.

Well in debug this what I get. it seems to be crashing in printf. This is in x86_64. Since I am not familiar
with LLVM tools, you will have to give me clue on what to run.

Starting program: /Volumes/Rafi/Developer/MacRuby/miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb ext/extmk.rb --make="/usr/bin/make" --dest-dir="" --extout=".ext" --mflags="" --make-flags="" --extension --extstatic
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries ++++++++.................... done
compiling bigdecimal

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff80b5ec53 in ffi_prep_cif ()
(gdb) bt
#0 0x00007fff80b5ec53 in ffi_prep_cif ()
#1 0x00000001001025ac in rb_str_format ()
#2 0x00000001000ab8b6 in rb_f_sprintf ()
#3 0x00000001000398d1 in rb_io_printf ()
#4 0x00000001000f3d50 in call_cfunc ()
#5 0x00000001000f2945 in vm_call_method ()
#6 0x00000001000e37b5 in vm_eval ()
#7 0x00000001000efd74 in vm_eval_body ()
#8 0x00000001000de20b in invoke_block_from_c ()
#9 0x00000001000dbe19 in rb_yield_values ()
#10 0x000000010001cc8e in each_with_index_i ()
#11 0x00000001000de2c5 in invoke_block_from_c ()
#12 0x00000001000dbc99 in rb_yield ()
#13 0x00000001000021eb in rb_ary_each ()
#14 0x00000001000f3d5d in call_cfunc ()
#15 0x00000001000db2ee in vm_call0 ()
#16 0x00000001000f4e6d in rb_call0 ()
#17 0x00000001000dc15e in iterate_method ()
#18 0x00000001000dbff6 in rb_iterate ()
#19 0x00000001000dc0cd in rb_block_call ()
#20 0x000000010001bf77 in enum_each_with_index ()
#21 0x00000001000f3d50 in call_cfunc ()
#22 0x00000001000f2945 in vm_call_method ()
#23 0x00000001000e37b5 in vm_eval ()
#24 0x00000001000efd74 in vm_eval_body ()
#25 0x00000001000efcef in rb_iseq_eval ()
#26 0x0000000100025e2a in rb_load ()
#27 0x0000000100026975 in rb_f_load ()
#28 0x00000001000f3d50 in call_cfunc ()
#29 0x00000001000f2945 in vm_call_method ()
#30 0x00000001000e37b5 in vm_eval ()
#31 0x00000001000efd74 in vm_eval_body ()
#32 0x00000001000de20b in invoke_block_from_c ()
#33 0x00000001000dbc99 in rb_yield ()
#34 0x00000001000021eb in rb_ary_each ()
#35 0x00000001000f3d5d in call_cfunc ()
#36 0x00000001000f2945 in vm_call_method ()
#37 0x00000001000e37b5 in vm_eval ()
#38 0x00000001000efd74 in vm_eval_body ()
#39 0x00000001000efcef in rb_iseq_eval ()
#40 0x000000010002366f in ruby_exec_node ()
#41 0x00000001000236cf in ruby_run_node ()
#42 0x000000010010ae4f in main ()
(gdb)

2009/3/28 रजनीश <rdogra@earthlink.net>

It basically segments faults

It would be wonderful if you could debug this and get down to the
root problem and then report it.

Well in debug this what I get. it seems to be crashing in printf.
This is in x86_64. Since I am not familiar
with LLVM tools, you will have to give me clue on what to run.

The basic strategy is just like debugging a regular crash, but with a bit more pessimism about who you can trust. From the trace below, it looks like there is a null pointer dereference, so the obvious questions are why is the value dereferenced null (is it non-null when built with gcc?) or why is the program dereferencing it (does gcc take a different path)?

Once you understand the basics of why the program is crashing, the next step is to try and understand what it is about the code that is causing clang to miscompile it, and then either recreate the problem in a small test case. However, if you manage to isolate the problem down to function A in source file B is miscompiled, feel free to file a bug with the preprocessed version of the source file and a reference to the function that is miscompiled.

  • Daniel