I have an arm board and would like to run mono on it...
~ # cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 131.48
Features : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
And cross compiler gcc 3.3.4 with uclibc.
Does anyone has any idea if this is even enough to crosscompile mono... It is a Armv5 so ?
Did anyone succeed to build mono for similar configuration? Can you please give me configuration instructions for cross compilation?
Thank you!
Related
I have been using python-libevent (https://pypi.org/project/python-libevent/) with multiple
versions of Python without any issues. Now, when I am trying to migrate to Python-3.8,
I see that a event_add() from my C code segfaults! and I am not getting much
from the backtrace/gdb!
I tried with python3.8-dbg and rebuilding libraries with debug symbols, still not getting
any clues!
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007fe4bc2f804e in event_add (ev=0x7fe4bba0d000, tv=0x7fe4bba0c020) at event.c:2443
where
2443: EVBASE_ACQUIRE_LOCK(ev->ev_base, th_base_lock);
Can anyone please help me on how to debug this further! I checked that I have enabled
pthreads and debug:
evthread_use_pthreads();
evthread_enable_lock_debugging();
event_enable_debug_mode();
event_enable_debug_logging(EVENT_DBG_ALL)
Has anything changed in the usage of libpython APIs - related to
memory-handling/capsules between 3.6 and 3.8 ? (my code works up until Py3.6)
libevent version: 2.1.8-stable
Py3.8 version: 3.8.0
Any help/pointers to debug much appreciated.
--More info--
After debugging with valgrind (helgrind tool) I see :
==13558== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==13558== Bad permissions for mapped region at address 0x0
==13558== at 0x0: ???
In my module, when I call event_add()!
Is there any restriction on
adding event to a event-base owned by a different module ?
I compile a macOS driverkit system extension as a Universal library so that it contains both x86_64 and arm64. One Apple Silicon computer A the driver starts when I attach the USB device. On Apple Silicon computer B I can see kernel: exec_mach_imgact: disallowing arm64 platform driverkit binary "com.example.driver", should be arm64e being printed in the Console.app when the USB device is attached. I've looked at the source code
of where this is happening but I cannot figure out what the problem is.
If I compile it for arm64e then it get exec_mach_imgact: not running binary "com.example.driver" built against preview arm64e on computer A, bit then it starts on computer B.
None of the computers have -arm64e_preview_abi set in the boot-args.
If I create a new Xcode (12.4) project on each machine and build Release then computer A and otool -fvv com.example.driver gives
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 73856
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 98304
size 73856
align 2^14 (16384)
On computer B the same command gives
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 73280
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 98304
size 73296
align 2^14 (16384)
How can I make the driver start on both machines?
Dexts should indeed be arm64 and x86_64 (but as pmdj explains, system binaries are still arm64e.)
As hinted by the name of (and need for) the -arm64e_preview_abi, arm64e is currently only exposed as a developer preview, to allow for testing.
However, you shouldn't get the disallowing arm64 error: did you set other interesting boot-args on computer B? (in particular, amfi= may be relevant)
My experience so far indicates that arm64e is the correct and only correct Apple Silicon architecture to use for dexts.
For one, there's the "disallowing arm64 platform" error, and also Apple's own DriverKit based drivers are built for arm64e:
% otool -fvv /System/Library/DriverExtensions/com.apple.AppleUserHIDDrivers.dext/com.apple.AppleUserHIDDrivers
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 96208
align 2^14 (16384)
architecture arm64e
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64E
capabilities CPU_SUBTYPE_ARM64E_PTRAUTH_VERSION 0
offset 114688
size 95312
align 2^14 (16384)
That leaves the question of why your arm64e build isn't working. The "built against preview arm64e" error suggests the problem isn't with the computer but the binary. Are you using identical binaries on the 2 systems? Perhaps one has SIP disabled, so it's more permissive of badly built binaries?
Have you tried a "hello world" style dext, in a freshly created project on the latest version of Xcode? Check that runs natively on both machines. Once that's working, compare Xcode's compiler and linker command lines with those from your build script - or if you're also using Xcode, compare your target's build settings with the "clean" one.
I've been trying to build Mono 3.2.3 on Solaris 11 with no luck. I've made a few minor code changes and turned off configuration features to get to this point but now I'm stuck with mono crashing while trying to build System.dll. Any ideas?
MONO_PATH="./../../class/lib/basic:$MONO_PATH" /home/axsadm/mono-3.2.3/runtime/mono-wrapper ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
+ r=/home/axsadm/mono-3.2.3
+ MONO_CFG_DIR=/home/axsadm/mono-3.2.3/runtime/etc
+ PATH=/home/axsadm/mono-3.2.3/runtime/_tmpinst/bin:/usr/bin:/usr/sbin
+ MONO_SHARED_DIR=/home/axsadm/mono-3.2.3/runtime
+ export MONO_CFG_DIR MONO_SHARED_DIR PATH
+ [ -n '' ]
+ exec /home/axsadm/mono-3.2.3/libtool '--mode=execute' /home/axsadm/mono-3.2.3/mono/mini/mono --config /home/axsadm/mono-3.2.3/runtime/etc/mono/config ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
* Assertion at threads.c:1001, condition `info' not met
Native stacktrace:
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_handle_native_sigsegv+0x1b8 [0x187c58]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'sigabrt_signal_handler+0xa0 [0x1ed97c]
/lib/libc.so.1'__sighndlr+0xc [0xff0254f0]
/lib/libc.so.1'call_user_handler+0x370 [0xff018e50]
/lib/libc.so.1'sigacthandler+0x58 [0xff019040]
/lib/libc.so.1'_lwp_kill+0x8 [0xff029fa0]
/lib/libc.so.1'abort+0xc8 [0xfefaac2c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_g_logv+0x174 [0x3d5454]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_assertion_message+0x38 [0x3d54e8]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach_full+0x2bc [0x2dc650]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach+0x10 [0x2dc37c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_runtime_init+0x23c [0x314034]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mini_init+0x1a60 [0x77158]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main+0x232c [0x1457a4]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main_with_options+0x48c [0x5fa30]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'main+0x2c [0x5fa74]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'_start+0x5c [0x5f3e4]
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
gmake[8]: *** [../../class/lib/build/tmp/System.dll] Abort (core dumped)
Configuration:
Engine:
GC: included Boehm
TLS: pthread
SIGALTSTACK: no
Engine: Building and using the JIT
oprofile: no
BigArrays: no
DTrace: no
LLVM Back End: no (dynamically loaded: no)
Libraries:
.NET 2.0/3.5: yes
.NET 4.0: yes
.NET 4.5: yes
MonoDroid: no
MonoTouch: no
JNI support: IKVM Native
libgdiplus: assumed to be installed
zlib: system zlib
This might be a bit late, but for me I had more luck using the external Boehm GC as opposed to the bundled/included one.
./autogen.sh --prefix=/usr --disable-dtrace --with-sgen=no --with-gc=boehm
This seemed to work OK for Solaris 10 and 11 on Intel. I'm still working on SPARC!
Good luck,
Steve
Newbie here. I have a big finite analysis code that needs to be run with high performance computing. People keep telling me Intel compiler usually gives better speed (I used to use gcc before). And I found that it is true on our Intel clusters. But recently we have a new AMD cluster. I am confused about how to use the compiling options of icpc to optimize the program.
Basically, I have two questions:
Questions 1
Here is the cluster with AMD chips:
processor : 63
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD Opteron(tm) Processor 6378
stepping : 0
cpu MHz : 2399.837
cache size : 2048 KB
physical id : 2
siblings : 16
core id : 7
cpu cores : 8
apicid : 79
initial apicid : 79
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nonstop_tsc extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr tbm topoext perfctr_core cpb npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips : 4799.73
TLB size : 1536 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate [9] [10]
When I compile a small code using icpc hello.cpp -O3 -xP, I do not know exactly what options should I use? I found the errors are:
$ /usr/bin/time -p ./a.out
Fatal Error: This program was not built to run on the processor in your system.
The allowed processors are: Intel(R) Pentium(R) 4 and compatible Intel processors with Intel(R) Streaming SIMD Extensions 3 (Intel(R) SSE3) instruction support.
real 0.00
user 0.00
sys 0.00
Question-2
If I want the binaries be used for both Intel chips cluster and AMD chips cluster, should I use different options to compile the code?
Intel compilers don't always work with AMD chips especially with certain flags like -xP (now -xSSE3, see here). Specifically -xSSE3/-xP tells the compiler: May generate Intel® SSE3, SSE2, and SSE instructions for Intel® processors. Optimizes for Intel processors that support Intel® SSE3 instructions. For OS X* systems, this value is only supported on IA-32 architecture. This replaces value P, which is deprecated.
That document also has this quote: Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
You can try to optimize with icc and icpc, but I'm not sure it will work on AMD chips. For compilers other than gcc you could look at clang, PGI, or Cray compilers (if you are on a Cray system).
If you're trying to create binaries for both architectures, I'm not sure you'll be able to do heavy optimizations due to differences in cache line size and other architecture specific settings.
I am trying to cross-compile Mono framework (3.0.6) for MIPS platform. There are few issues I have found so I would like to ask the community whether there are known or not.
My environment: Linux 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Toolchain: Sourcery G++ Lite 4.3-51
command-line:
./configure --prefix=/home/dev/mono-3.0.6-mips --host=mips-linux-gnu --enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs --target=mips-linux-gnu --with-moonlight=no --with-tls=pthread --with-sigaltstack=no --with-profile4_5=yes CXXFLAGS="-mips32r2 -march=24kf -mtune=24kf -EL" CFLAGS="-mips32r2 -march=24kf -mtune=24kf -EL" && make
Issue #1:
When I managed it to configure, compilation stopped with the following error:
mini-gc.c:2551: error: redefinition of 'mini_gc_enable_gc_maps_for_aot'
mini-gc.c:2518: error: previous definition of 'mini_gc_enable_gc_maps_for_aot' was here
Issue #2:
After I commented out the second declaration of mini_gc_enable_gc_maps_for_aot it compiled but looks like Sourcery G++ linker crashed:
/home/dev/mips-4.3/bin/../lib/gcc/mips-linux-gnu/4.3.2/../../../../mips-linux-gnu/bin/ld: BFD (Sourcery G++ Lite 4.3-51) 2.18.50.20080215 assertion fail /scratch/clm/2008q3-lite/obj/binutils-src-4.3-51-mips-linux-gnu-i686-pc-linux-gnu/bfd/elfxx-mips.c:2651
Could anyone led some light to this problem? I failed to find any articles/info describing building Mono for MIPS architecture (at least some recent information). According to this link, support for MIPS was added about a year ago. Mono itself should fully support MIPS since 3.0.4 version.
I am posting this info for everyone else who will struggle with the same problem (building Mono for MIPS platform):
At last I was able to build mono runtime for MIPS platform using the following command line:
./configure --prefix=/home/dev/mono-3.0.6-mips --host=mips-linux-gnu --enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs --target=mips-linux-gnu --with-moonlight=no --with-tls=pthread --with-sigaltstack=no --with-profile4_5=yes CXXFLAGS="-mips32r2 -EL" CFLAGS="-mips32r2 -EL" LDFLAGS=-EL CPPFLAGS="-mips32r2 -EL" ASFLAGS=-EL CC="mips-linux-gnu-gcc -EL"
Specifying -EL flag for all the tools fixed issue with mono linking using ld (see Issue #2 in my initial post).
The last issue left is to make the mono build system to build mscorlib.dll. Invoking different make commands inside mcs/class folder doesn`t do anything.