I have NetBSD5.1 source. I have compiled the kernel and userland with the source. When I native compile a sample C program with pthread_create() in ARM NetBSD5.1, it is crashing. Same program is running successfuly in my Linux PC. Want to know if Pthread is supported in ARM machine which run NetBSD5.1 OS?
Note: other sample C programs native compiled in ARM machine runs successfully.
It should work, I think. (I don't have an ARM system running 5.1 at the moment -- mine are running a pre-7.0 -current.)
If you can show some more details about the crash, e.g. stack backtraces from the debugger, then perhaps I or someone else can provide more help.
Related
I need to implement a system with a third party device using a Raspberry Pi.
The device is connected using USB, and the manufacturer has provided a few software implementation demos, and the driver library includes a C++ header file and a C shared object file compiled for i386.
I need to be able to run this driver library on the RPi. My idea is to build a C++ program I can use to get the data from the device, compile for i386, and run it with qemu-i386. I have tried to execute this idea, but have run into some problems relating to the linking, like the executable looking for ld-linux.so.2, which my RPi doesn't have.
How can I get this to work?
It's a bad idea to run it for QEMU, instead install box86, link, it'll automatically take over when it detects a 32bit x86 executable and should work great for your use case
Years ago,I had created a program using TurboC IDE and This program can also be run using DOSbox. Now,when I tried to run any program which was compiled using GCC in DOSbox,this message came:
This program cannot be run in DOS mode
So my question is,Why isn't it possible to run programs compiled using GCC in DOSbox,while those compiled from TurboC are?
PS:The reason that I want to run them in DOSbox is that I want to run those programs in my phone(which has DOSbox installed).
Because MS DOS is 16-bit operating system and has no support for the 32-bit programs. Also modern operating systems has much stricter view on the direct hardware access, so modern programs must work through some hardware abstraction layers, which are also missing in the MS DOS.
There is a GCC distribution called "DJGPP" which enables programs to be compiled using GCC, and uses DPMI to achieve this. Dos Protected Mode Interface, you have to run the program in protected mode, basically. There are other C environments such as Watcom that did the same thing, but I don't think Borland ever did anything with it.
I would like to know if it would be possible to cross-compile application written in Ocaml on processor like STM32F407 (1MB Flash, 196kB RAM) ? (without OS).
I have read Cross-compiling ocaml apps for ARM ; the experiment seems to have been done on beaglebone; so more powerfull than STM32, and with Linux as OS.
There is also OcaPIC (http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=ocapic) - which is meant for PIC processors.
Is there any similar port for ARM Cortex M4 ?
I'm not aware of a port, but see the related mailing list thread 1,2.
To get started you could use the same toolchain that you use for building a C or Arduino code to cross-compile the OCaml bytecode interpreter (ocamlrun), and then run 32-bit OCaml bytecode.
The tricky part would be to port the runtime to work without an OS (allocating memory, etc.). Projects like Mirage have done that for Xen based partially on Xen's miniOS.
Perhaps you could use FreeRTOS, ChibiOS, etc. to get started.
Once that works you can look at native code with ocamlopt, it supports armv4 to armv7, but I don't know if ARMv7E-M is a superset of that or not.
Or you could write a DSL embedded in OCaml that generates C code which you would finally run on your MCU, like Haskell does with Ivory3 and Atom4.
The question says it all. I need to cross-compile for a Cyrix CPU. The system the compiler (doesn't have to be gcc) needs to run on is a 64bit Kubuntu, with an i5 processor. I couldn't find anything useful googling, except for a piece of information saying that "Cx486DX is software-compatible with i486". So I ran
gcc -m32 -march=i486 helloworld.c -o helloworld486.bin
but executing helloworld486.bin on the Cyrix machine gives me a floating point exception. My knowledge about CPUs is rather limited and I'm out of ideas now, any help would be really appreciated.
Unfortunately you need more than just a compiler that generates instructions for the 486. The compiler libraries, as well as any libraries that are linked in statically should be suitable as well. The GCC version included in most current Linux distributions is able to generate 486-only object files (I think), but its libraries and stub objects (e.g. crtbegin.o) have been pre-generated for 686 CPUs.
There are two main alternatives here:
Use a Linux build system that is compiled for 486 itself, either in a VM or in a chroot jail. Unfortunately getting a modern Linux distribution for the 486 is a bit of an issue - every single major distribution has moved on. Perhaps a (much) older Linux distribution would be of help?
Create a full cross-compiler toolchain for the 486. You can then cross-compile separate versions of all needed libraries and have your build scripts use them. Quite honestly, ensuring that nothing from the (usually 686-based) build host slips through to the build result is not very easy. It oftens amounts to cross-compiling a whole Linux system from scratch, ala CLFS.
An automated cross-compiler toolchain build script, such as crosstool-ng might be of help.
Could you add more details about your target system? Is it an embedded system or just an old PC? What OS is it using? Would it be possible to just run your compile in a VM with a version of the target OS?
Is there any way for instrumenting an ARM binary using Valgrind which runs on a X86/Linux?
No, Valgrind does not "instrument" binaries. It runs the unmodified binary inside an emulator (well, you can view it like that anyway), and intercepts the memory accesses as they happen.
Valgrind is therefore highly architecture-specific, and the Valgrind that runs on x86 can do nothing useful with an ARM binary.
However, Valgrind does have (possible incomplete) support for the ARMv7 architecture, so you should be able to run that on your target device and analyse your code that way.
If Valgrind will not work reliably with your device (not enough memory? Too slow?) then you might try running it on the x86 machine inside QEMU (user mode). On Ubuntu (and probably other distros) it is sufficient to install the QEMU package, and then ARM binaries will magically run via translation, as if they were on the target, with no further effort (although dynamically linked binaries will have difficulties finding their libraries). You can then run Valgrind for ARM and your own code on your development machine.