Many questions in this forum start with "why does my code not run..." For a change, this one is "why does my code run..."
I develop on Ubuntu 18.04 running as a VM machine on a laptop (windows x86).
The following program compiled and linked with gcc runs fine and displays a 64 bit address.
char *s = "Hello\n"; printf ("Hello at address: %p\n", s);
My assumption is that arm-none-eabi targets a system bare metal. Of course I am not trying to run the above program on a bare metal. But I am trying to understand how cross compilation works.
The same program compiled and linked with arm-none-eabi-gcc (installed from Ubuntu) indicates a lot of missing references (_exit ...etc.) - normal. The code created is ARM assembly language, I verified with arm-none-eabi-objdump.
Adding the option --specs=nosys.specs at load time solves the missing references - as expected. When I run it on Ubuntu, QEMU is automatically called and has a segmentation fault. I am not surprised about the segmentation fault but the automatic launch of QEMU was unexpected.
Changing the option to --spec=rdimon.specs also solves the missing references - as expected. But despite the assembly code created is arm, it runs on Ubuntu (x86). The address displayed is 32 bits.
I know that rdimon.specs relates to semi-hosting, but I thought this was only activated when the program runs on the target (arm processor) and communicates with the host running gdb. Apparently I am wrong.
Sorry about this long preamble...simple question: how is it that my arm code runs on x86?
This is a result of the binfmt mechanism. When qemu is installed, it registers itself to run non-native executables, and is transparently invoked when a non-native ELF is executed. When semihosting is enabled using rdimon specs, it links a suitable set of libc stubs which cooperate with the host environment.
Related
I have Qt application that is displaying a WebView (webkit based). I am attempting to debug it using gdb. When I run the application through gdb it crashes almost immediately. The application runs without issues when executed outside of gdb.
The reason for the crash is:
Thread 1 "myapp" received signal SIGILL, Illegal instruction.
0x4a4d9a88 in ?? () from /usr/lib/libcrypto.so.1.0.2
Since the error is SIGILL is it possible that gdb is loading the lib from the wrong path?
The application is really simple, just displays a WebView at specific URL:
ui->webView->page()->mainFrame()->setUrl(QUrl(urlString));
The application crashes in gdb after the line above is executed.
The environment is an embedded system running linux on an arm architecture:
Linux hh4 3.1.10-2.8.5+g841700f8a2ea #1 SMP PREEMPT Fri May 3 18:48:07 UTC 2019 armv7l GNU/Linux
Any help in understanding why the app is crashing in gdb is appreciated.
GDB loading the wrong library is a possibility.
An easy way to find out is to set a breakpoint on main() - by which point you'd expect the library to memory-mapped into the process.
You can probably use GDB to check, alternatively, get a shell on the target system and run
losf -p <process_id>
This will list all open file-handles owned by the process - including all shared libraries that are memory mapped.
If you are somehow using the development host's libraries this would definitely explain it.
I am using my own laptop locally with win 10 system and intel parallel studio .
After I compiled my mpi code with mpiifort and run it with mpiexec for the first time. It warns me to input account and password, like below
I am sure I put in the correct password. But it just didn't work. What does "execvp error" mean? I never encountered this problem before on my old win8 system. I just installed this new win10 system on my laptop, everything is new. Could somebody please help me instead of making close vote without any comment? At least, say something
execvp error on file is the error from doing execvp system call. It is variant of exec system call used to start programs. In your case the mpiexec program tries to start the mpi-learning-pack.exe file on the target hosts (according to settings, probably some environment settings). This error says that it can't start your program on target hosts, because either it is not executable file, or cannot be found (not copied to target hosts or have no full path).
mpiexec does not copy file to targets, you should copy it to every target hosts.
You can also check if it executable by manually starting it on target host: just login to target host and type mpi-learning-pack.exe without mpiexec;
program may not start if there are no any of required library on target.
Or your account has no enough privileges like https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/607844 https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/624054
Or you just should use relative (mpiexec [options] .\mpi-learning-pack.exe) or full path (mpiexec [options] e:\w\work\fortran\_test_and_learning\mpi-learning-pack.exe) of target executable like in https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/624054
I'm about to start learning PowerPC architecture and as an example of I've downloaded some reference manuals from NXP website as well as theirs SDK so I can build even bareboard applications. To be precise I'm using virtual host environment. I don't have any board with PowerPC processor on it so I would like to use a simulator for debugging.
At this step I'm a little confused. So, I've built an bareboard application (a 'Hello World' one). And now I'd like to run it with simulator. I've tried to use a command like this: qemu-system-ppc -machine ppce500 -cpu e500v2 -nographic -kernel ./a.out and saw nothing. The qemu just loads host CPU. ./a.out is the binary built with command $CC -static ./tst.c. So, now I don't even know how to deal with qemu.
For those, who would like to help: I'm using Virtual Host environment for Freescale P1010 processor with e500v2 core, the binary was built with theirs fsl-* utilities.
The source compiled was:
$ cat ./tst.c
#include <unistd.h>
#define STRING "This is a test.\n"
int main(void) {
write(1, STRING, sizeof(STRING) - 1);
return 0;
}
Compilation took place like:
$ echo $CC
powerpc-fsl-linux-gnuspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double --sysroot=/opt/fsl-qoriq/1.9/sysroots/ppce500v2-fsl-linux-gnuspe
$ $CC -static -o tst.bin ./tst.c
$ file ./tst.bin
./tst.bin: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=63b307e7afe9de0b2781f2f92b5f1b3a803f850d, not stripped
Other than using a simulator, Why don't you ask for a real free virtual machine to do development/learning? From what you say, it should work better.
You can ask a VM in the following sites:
[Brazil] http://openpower.ic.unicamp.br/minicloud/
[China] https://dashboard.ptopenlab.com
You're not seeing anything as you're asking qemu-system-powerpc to run a userspace binary rather than a kernel.
If you're just wanting to poke at userspace programming, try the qemu-ppc binary instead, as that will run 32bit PowerPC userspace by doing things like translating syscalls.
Another option, if you want to program the bare metal, is to start writing your own tiny OS to a specific machine type (i.e. you're going to have to implement that write() call you're calling).
I am trying to start working with OpenCL. I have two NVidia graphics card, I installed "developer driver" as well as SDK from NVidia website. I compiled the demos but when I run
./oclDeviceQuery
I see:
OpenCL SW Info:
Error -1001 in clGetPlatformIDs Call
!!!
How can I fix it? Does it mean my nvidia cards cannot be detected? I am running Ubuntu 10.10 and X server works properly with nvidia driver.
I am pretty sure the problem is not related to file permissions as it doesn't work with sudo either.
In my case I have solved it by installing nvidia-modprobe package available in ubuntu (utopic/multiverse). And the driver itself (v346) was installed from https://launchpad.net/~mamarley/+archive/ubuntu/nvidia
Concretely, I have installed nvidia-opencl-icd-346, nvidia-libopencl1-346, nvidia-346-uvm, nvidia-346 and libcuda1-346. Not sure if they are all needed for OpenCL.
This is a result of not installing the ICD portion of Nvidia's openCL runtime. The ICD profile will instruct your application of the different openCL implementations installed on the system as multiple implementations from different vendors can coexist. Whe your application does not find the ICD information it gives the Error -1001.
Run your program as root. In case of success: you have trouble with cl_khr_icd- extension to load the vendor driver.
If you not running X11, you have to create device files manually or by (boot-)script:
ERROR: clGetPlatformIDs -1001 when running OpenCL code (Linux)
Same problem for me on a Linux system. Solution is to add the user to the video group:
# sudo usermod -aG video your-user-name
Since I just spend a couple of hours on this, I thought I would share:
I got the error because I was connected to the machine per remote desktop (mstsc). On the machine itself everything worked fine.
I have been told that it should work with TeamViewer by the way.
Dont know if you ever solved this problem, but I had the same issue and solved it in this post: ERROR: clGetPlatformIDs -1001 when running OpenCL code (Linux)
Hope it helps!
I have solved it in Ubuntu 13.10 saucy for intel opencl by created link:
sudo ln -s /opt/intel/opencl-1.2-3.2.1.16712/etc/intel64.icd /etc/OpenCL/vendors/nvidia.icd
I just ran into this problem on ubuntu 14.04 and I could not find ANY working answers anywhere online including this thread (though this was the first to show up on google). What ended up working for me was to remove ALL previous nvidia software and then to reinstall it using the .run file provided on the nvidia website. Installing the components through apt-get seems to fail for some reason.
1) Download CUDA .run file: https://developer.nvidia.com/cuda-downloads
2) Purge all previous nvidia packages
sudo apt-get purge nvidia-*
3) Install all run file components (you will likely have to stop X or restart in recovery mode to run this)
sudo sh cuda_X.X.XX_linux.run
This is because OpenCL has the same brain damaged one library per vendor setup that OpenGL has. A likely reason for the -1001 error is that you have compiled with a different library than the linker is trying to dynamically load.
So see if this is the problem run:
$ ldd oclDeviceQuery
...
libOpenCL.so.1 => important path here (0x00007fe2c17fb000)
...
Does the path point towards the NVidia-provided libOpenCL.so.1 file? If it doesn't, you should recompile the program with an -L parameter pointing towards the directory containing NVidia's libOpenCL.so.1. If you can't do that, you can override the linker's path like this:
$ LD_LIBRARY_PATH=/path/to/nvidias/lib ./oclDeviceQuery
For me, I was missing the CUDA OpenCL library, Running sudo apt install cuda-opencl-dev-12-0 solved it.
You should get number of platforms, allocate the memory for platforms, again get this platforms and then create context from this platform. There is good example:
http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=71
This might be due to querying clGetPlatformIDs by multiple threads at the same time
I'm trying to build an application from source in windows that requires some Unix tools. I think it's the apparently standard ./configure; make; make install (there's no INSTALL file). First I tried MinGW but got confused that there was no bash, autoconf, m4, or automake exes in \bin. I'm sure I missed something obvious but I installed Cygwin anyways just to move forward. For some reason when I run
sh configure.sh
I get:
platform unix
compiler cc
configuration directory ./builds/unix
configuration rules ./builds/unix/unix.mk
My OS has identity problems. Obviously the makefile is all wrong since I'm not on unix but win32. Why would the configure script think this? I assume it has something to do with Cygwin but if I remove that I can't build it at all. Please help; I'm very confused.
Also is it possible to build using MinGW? What's the command for bash and is mingw32-make the same as make? I noticed they're different sizes.
Everything is fine. When you are inside CygWin, you are basically emulating an UNIX. sh runs inside CygWin, and thus identifies the OS correctly as Unix.
Have a look at GCW - The Gnu C compiler for Windows
Also, you might be interested in this help page, that goes into some detail about the minimal system (MSYS), such as how to install, configure et. c.
That should help you get bash, configure and the rest to work for MinGW as well.
From the Cygwin home page
Cygwin is a Linux-like environment for Windows. It consists of two parts:
A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.
A collection of tools which provide Linux look and feel.
Since configure is using the Cygwin environment, it is interacting against the emulation layer and so it is just like it's working on a Unix environment.
Have you tried building the application and seeing if it works?