[M3devel] ARMEL_LINUX on Raspberry Pi progress report
Jay K
jay.krell at cornell.edu
Wed Oct 16 22:54:35 CEST 2013
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
More information about the M3devel
mailing list