[M3devel] ARMEL_LINUX on Raspberry Pi progress report

Wed Oct 16 23:02:55 CEST 2013

I likely addressed the TLS and m3_eq_ADDRESS problem.
TLS could use more investigation, but ok.
m3_eq_ADDRESS maybe double checking/testing.
BadPercentage I can try to look at later...do we have any non-Trestle GUI apps that use Xlib more directly? Try those?
Try a C/C++ GUI app?

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: mika at async.caltech.edu
> Date: Wed, 16 Oct 2013 20:54:35 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ARMEL_LINUX on Raspberry Pi progress report
>
> TLS: On Linux and only Linux we use __thread as a possible
> optimization. On all other Posix platforms we use
> pthread_setspecific/pthread_getspecific.
> Several other platforms support this, but not always older versions.
>
>
> You compiled with -fPIC?
> Or did you/we just cc -c *.c ?
>
> I suppose..in m3core/src/thread/PTHREAD/ThreadPThreadC.c
> change:
>
> #if defined(__linux)
> to
> #if defined(__linux) && !defined(__arm__)
>
>
> Search the web for the warning?
> I can't right now.
>
>
> m3_eq_ADDRESS: This is slow/not-inline because
> For a long time I was avoiding gcc warnings, unconditionally.
> When using -Wall -Wextra. That is tricky.
> It warns about stuff like:
> unsigned a = 0;
> if (a < 0) // always false
> and I worked around it by introducing functions for all such
> comparisons. I tried value tracking to make the optimizations
> myself, but that has failed so far.
>
>
> But upon stepping into those functions a lot on AMD64_NT,
> I did make it conditional, but didn't finish testing.
>
>
> The relevant code is in m3back/src/M3C.m3:
> "#if (GCC_VERSION> 0 && GCC_VERSION < 430)",
> "#define m3_eq_T(T) static WORD_T __stdcall m3_eq_##T(T x, T y){return x==y;}\n" &
>
> Can you do cm3 -keep and the gcc -E on some files?
> I'll do that later.
>
> Oh, maybe:
> "#define GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__)",
> with:
> "#define GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__ * 10)",
>
> I'm torn on this matter.
> I like my code to be warning free, but catering to
> gcc 4.0 -Wall -Wextra isn't easy.
>
>
> BadPercentage:
> Um, to isolate variables, and cause you extra pain..
> try with cm3cg?
> You know, try a different implementation to help
> determine where the problem is?
> Something floating point related?
>
>
> - Jay
>
> ----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Wed, 16 Oct 2013 13:31:05 -0700
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report
>>
>>
>> It's still working its way through boot2.sh ..
>>
>> here is what I have run into so far that looks wrong:
>>
>> 1. I get the following warning whenever I link a program (I think only as
>> "mika", not as "root"):
>>
>> new source -> compiling Main.m3
>> -> linking tnmtsetup
>> /usr/bin/ld: /usr/local/cm3/pkg/m3core/ARMEL_LINUX/libm3core.a(ThreadPThreadC.o)(.stab+0x2e28): R_ARM_ABS32 used with TLS symbol activations
>>
>> I think it's just a warning because the executables still work.
>>
>> 2. I can't get anything with Trestle working. I'm running in a VNC
>> session on a remote machine. Not sure this has anything to do with the
>> compiler or even the ARM. Has anyone seen it before (on any system)?
>>
>> (gdb) cont
>> Continuing.
>> [New Thread 0x42276430 (LWP 24451)]
>> [Thread 0x42276430 (LWP 24451) exited]
>> [New Thread 0x424c6430 (LWP 24454)]
>>
>>
>> ***
>> *** runtime error:
>> *** Exception "ZChildVBT.BadPercentage" not in RAISES list
>> *** file "../src/lego/ZChildVBT.m3", line 61
>> ***
>>
>>
>> Program received signal SIGABRT, Aborted.
>>
>> backtrace:
>>
>> (gdb) where
>> #0 ZChildVBT__Init (z_L_120=0x422bbf70 "H\357K", ch_L_121=0x422bdb84 "\260\326K", h_L_122=0, v_L_123=1.75, loc_L_124=4 '\004', type_L_125=1 '\001', shaper_L_126=0x41a32b54, open_L_127=0 '\000') at ../src/lego/ZCh
>> ildVBT.m3:61
>> #1 0x40637518 in FormsVBT__pZChild (cl_L_1042=0x42280444, list_L_1043=0x424c54c4, s_L_1044=0x424c55dc) at ../src/FormsVBT.m3:2593
>> #2 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a45994 "", state_L_303=0x424c55dc) at ../src/FormsVBT.m3:250
>> #3 0x40648b3c in FormsVBT__AddChildren (cl_L_1229=0x42280444, v_L_1230=0x422b0634 " \365K", list_L_1231=0x41a48504, state_L_1232=0x424c55dc) at ../src/FormsVBT.m3:3671
>> #4 0x40634138 in FormsVBT__pZSplit (cl_L_999=0x42280444, list_L_1000=0x424c56bc, s_L_1001=0x424c57c4) at ../src/FormsVBT.m3:2454
>> #5 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a40ec0 "", state_L_303=0x424c57c4) at ../src/FormsVBT.m3:250
>> #6 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c57c4) at ../src/FormsVBT.m3:3642
>> #7 0x406129c0 in FormsVBT__pShape (cl_L_496=0x42280444, list_L_497=0x424c58a4, s_L_498=0x424c59a4) at ../src/FormsVBT.m3:948
>> #8 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a402a4 "", state_L_303=0x424c59a4) at ../src/FormsVBT.m3:250
>> #9 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c59a4) at ../src/FormsVBT.m3:3642
>> #10 0x4062ca10 in FormsVBT__pScale (cl_L_905=0x42280444, list_L_906=0x424c5a84, s_L_907=0x42280458) at ../src/FormsVBT.m3:2165
>> #11 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a4006c "", state_L_303=0x42280458) at ../src/FormsVBT.m3:250
>> #12 0x40606dec in FormsVBT__Apply (cl_L_293=0x42280444) at ../src/FormsVBT.m3:84
>> #13 0x40d27bd4 in ThreadPThread__RunThread (me_L_231=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:449
>> #14 0x40d27590 in ThreadPThread__ThreadBase (param_L_229=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:422
>> #15 0x41850bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
>> #16 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
>> #17 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>> (gdb) cont
>> Continuing.
>>
>> 3. looking at the generated C and binaries I am wondering if everything
>> is quite all right. The binaries are twice as large as on x86_64 (give
>> or take). Mentor is 13MB...
>>
>> Looking at the C code it also looks to me like the intent was to inline things such as the following:
>>
>> 00000048 <m3_eq_ADDRESS>:
>> 48: e52db004 push {fp} ; (str fp, [sp, #-4]!)
>> 4c: e28db000 add fp, sp, #0
>> 50: e24dd00c sub sp, sp, #12
>> 54: e50b0008 str r0, [fp, #-8]
>> 58: e50b100c str r1, [fp, #-12]
>> 5c: e51b2008 ldr r2, [fp, #-8]
>> 60: e51b300c ldr r3, [fp, #-12]
>> 64: e1520003 cmp r2, r3
>> 68: 13a03000 movne r3, #0
>> 6c: 03a03001 moveq r3, #1
>> 70: e1a00003 mov r0, r3
>> 74: e28bd000 add sp, fp, #0
>> 78: e8bd0800 pop {fp}
>> 7c: e12fff1e bx lr
>>
>> yet it's not getting inlined but "threaded"...
>>
>> e.g.,
>>
>> (92)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep m3_eq_ADDRESS | wc
>> 79 237 1975
>>
>> or indeed:
>>
>> (95)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep ^0 | awk '{print $3}' | sort | uniq -c | sort -n | tail -50
>> 2 L_82_L_83
>> 2 m3_lt_float
>> 2 m3_max_float
>> 2 m3_min_float
>> 2 m3_trunc
>> 3 L_11_L_12
>> 3 L_17_L_18
>> 3 L_18_L_19
>> 3 L_19_L_20
>> 3 L_35_L_36
>> 3 L_46_L_47
>> 3 L_8_L_9
>> 3 m3_ge_float
>> 3 m3_le_float
>> 3 m3_mod_INT32
>> 3 m3_set_member
>> 3 m3_shift_UINT32
>> 4 L_7_L_8
>> 5 L_28_L_29
>> 5 m3_ne_float
>> 6 L_16_L_17
>> 6 L_21_L_22
>> 6 L_5_L_6
>> 7 L_3_L_4
>> 8 L_10_L_11
>> 8 m3_div_INT32
>> 9 L_0_L_1
>> 10 L_9_L_10
>> 10 m3_round
>> 11 L_14_L_15
>> 11 L_6_L_7
>> 11 m3_check_range_INT32
>> 12 m3_sign_extend_INT32
>> 13 L_2_L_3
>> 13 L_4_L_5
>> 15 L_1_L_2
>> 16 m3_pop_INT32
>> 18 m3_min_INT32
>> 22 m3_lt_INT32
>> 22 m3_max_INT32
>> 27 m3_eq_UINT32
>> 27 m3_le_INT32
>> 31 m3_gt_INT32
>> 42 m3_ne_UINT32
>> 57 m3_ge_INT32
>> 64 m3_ne_ADDRESS
>> 79 m3_eq_ADDRESS
>> 81 m3_extract_UINT32
>> 83 m3_ne_INT32
>> 208 m3_eq_INT32
>>
>> where... (judging from the macros in the .c this might be important):
>>
>> (96)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>gcc -v
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
>> Target: arm-linux-gnueabihf
>> Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
>> Thread model: posix
>> gcc version 4.6.3 (Debian 4.6.3-14+rpi1)
>>
>>
>>
>> Mika 		 	   		  