Check if my MVAPICH has multi-threading enabled - mpi

I wonder if there is any command to show the enabled features of an MVAPICH installation similar to the one that we can find for OpenMPI:
ompi_info
Especially, I am interested in knowing if multi-thread support is enabled.

I would recommend just running a simple test program like this:
#include <stdio.h>
#include <stdlib.h>
#include <mpi.h>
int main(void)
{
int lvlrequired, lvlprovided;
lvlrequired = MPI_THREAD_MULTIPLE;
MPI_Init_thread(NULL, NULL, lvlrequired, &lvlprovided);
if (lvlprovided < lvlrequired)
{
printf("Required level of threading support *not* available\n");
}
else
{
printf("Required level of threading support *is* available\n");
}
MPI_Finalize();
return(0);
}
On my Ubuntu laptop with standard OpenMPI:
me#laptop$ mpicc -o threadcheck threadcheck.c
me#laptop$ mpiexec -n 2 ./threadcheck
Required level of threading support *not* available
Required level of threading support *not* available
which agrees with ompi_info:
me#laptop$ ompi_info | grep THREAD_MULTIPLE
Thread support: posix (MPI_THREAD_MULTIPLE: no, OPAL support: yes, OMPI progress: no, ORTE progress: yes, Event lib: yes)
but if I request MPI_THREAD_SERIALIZED
me#laptop$ mpiexec -n 2 ./threadcheck
Required level of threading support *is* available
Required level of threading support *is* available
Hope this is useful.
David

Related

Qprocess and avrdude

i'm trying to create a simple QT program that allows me to launch avrdude without using command line operations.
I saw that with Qprocess it's easy to launch any kind of program and I tried succesfully with simple programs like Explorer Word and Others.
The problem is that when i try to open cmd.exe nothing happens, even if i try to pass a batch file containing all the information to launch correctly avrdude.
Here's the code
QProcess *process = new QProcess(this);
process->startDetached("cmd.exe",QStringList()<<"C:/avrdude/avr.bat");
I wrote a minimal sample application which shows how to start cmd with a command using QProcess::startDetached() (on button click):
// standard C++ header:
#include <iostream>
// Qt header:
#include <QApplication>
#include <QMainWindow>
#include <QPushButton>
#include <QProcess>
int main(int argc, char **argv)
{
// main application
#undef qApp // undef macro qApp out of the way
QApplication qApp(argc, argv);
QMainWindow qWin;
QPushButton qBtn(QString::fromLatin1("Start cmd"));
QObject::connect(&qBtn, &QPushButton::clicked,
[](bool) {
bool ret = QProcess::startDetached(
#if 1 // let Windows search for cmd.exe in %PATH%
QString::fromLatin1("cmd.exe"),
#else // define exact path of cmd.exe
QString::fromLatin1("C:\\Windows\\system32\\cmd.exe"),
#endif // 1
QStringList()
<< QString::fromLatin1("/K")
<< QString::fromLatin1("echo Hello"));
std::cout << "QProcess::startDetached():"
<< (ret ? "OK." : "Failed!") << std::endl;
});
qWin.setCentralWidget(&qBtn);
qWin.show();
return qApp.exec();
}
The Qt project file is left as exercise. (Sorry, I used CMake for this.)
Please, note the #if 1. If 1 is replaced by 0 the alternative code with full path is used. (During chat session we examined special problems with starting the cmd.exe.) On my system, both alternatives did as well.
(My system: Windows 10, VS2013, Qt 5.7)
I too have been working on a Qt program where there are a couple calls to AVRDUDE. This is what worked for me. Here's the code I made for a read of the AVR device through AVRDUDE, followed by a couple of comments.
void MainWindow::call_AVRDUDE_read() //AVR READ
{
QProcess CommandPrompt;
QStringList Arguments;
QString COMPortUsed = (ui->COM_Port_Used->text()); // get the COM port from the user off UI
Arguments << "/C avrdude -c arduino -P "+ COMPortUsed +" -b 115200 -p ATmega328P -e -U eeprom:r:fromEEPROM.bin:r";
CommandPrompt.start("cmd",Arguments);
CommandPrompt.waitForFinished();
}
Here's something else which may well influence things in your application. In my case, I am reading the AVR's EEPROM. There is another routine that writes the EEPROM, but it is essentially the same as above, but a different script is sent.
In BOTH these cases, the AVRDUDE operation takes a few seconds to perform its task. When you use the QProcess::startDetached(), it has the disadvantage that control will return IMMEDIATELY after the AVRDUDE script is called through the QProcess. This can cause problems, if for instance you wanted to (as in my case) read the contents of the EEPROM and try to do so before the read actually completes.
An alternative to startDetached() you might consider trying is shown below. This will retain control until the process is finished, which may be pretty important to you. Use these two lines to replace the startDetached() call you are currently using.
CommandPrompt.start("cmd",Arguments);
CommandPrompt.waitForFinished();
This will wait for the AVRDUDE process to finish before control is returned.
The take away here though is that QProces::startDetached() may return prematurely in your application. Just beware of that.

Intel Pin 3.0 does not recognize MPX instructions?

I have the latest version of Intel Pin 3.0 version 76887.
I have an MPX-enabled toy example:
#include <stdio.h>
int g[10];
int main(int argc, char **argv) {
int x = g[11];
printf("%d\n", x);
return 0;
}
When compiled with gcc + MPX, I see MPX instructions in the disassembly via objdump, and the example correctly writes me a bounds violation:
Saw a #BR! status 0 at 0x401798
Now I'd like to count the total number of specific MPX instructions using Intel Pin, e.g., BNDLDX and BNDMK.
My first attempt was using the shipped tool source/tools/SimpleExamples/trace.cpp. This tool showed me NOPs at places of MPX instructions.
In my second attempt, I wrote my own tool with the following snippet:
xed_iclass_enum_t iclass = (xed_iclass_enum_t)INS_Opcode(ins);
if (iclass == XED_ICLASS_BNDMK)
INS_InsertPredicatedCall(ins, IPOINT_BEFORE, (AFUNPTR)countBndmk, IARG_END);
This doesn't work, countBndmk is never called. I double-checked my code with other instruction iclasses, and they worked. So clearly there is a problem of Pin (or XED?) not recognizing MPX instructions.
Browsing the docs, I noticed an interesting knob
KNOB<BOOL> knob_mpx_mode(KNOB_MODE_WRITEONCE,"supported:xed","xed_mpx_mode","0","Enable Intel(R) MPX instruction decoding")
This knob seems to enable MPX decoding and is 0 by default, and I don't know how to enable it per command-line or in my tool. I found no other references to this problem in code or internet.
I know I could use Intel SDE to dump the debug trace including MPX instructions. I wonder if there is a way to enable MPX in Intel Pin. Or the only solution is to decode opcodes myself?
Maybe a little bit late to answer, but it seems that you have just to pass the option to PIN.
A little bit of background:
On the Intel manual there's this line (nothing to do with MPX, but it gives a clue):
Add the knob support_jit_api to the Pin command line as Pin tool option:
<Pin executable> <pin options> -t <Pin tool> -support_jit_api <Other Pin tool options> -- <Test application> <Test application options>
It happens there's an existing KNOB for this option:
KNOB<BOOL> LEVEL_PINCLIENT::KnobJitApi ( KNOB_MODE_WRITEONCE ,
"pintool:sym" ,
"support_jit_api" ,
"0" ,
"Enables the Jitted Functions Support"
)
As the MPX knob is defined as:
KNOB<BOOL> knob_mpx_mode(KNOB_MODE_WRITEONCE,"supported:xed","xed_mpx_mode","0","Enable Intel(R) MPX instruction decoding")
I guess you just have to pass the option to PIN:
<Pin executable> <pin options> -t <Pin tool> -xed_mpx_mode <Other Pin tool options> -- <Test application> <Test application options>
It seems that those KNOBs are hardcoded onto PIN / PinTools.

How to do OpenCL programming in the newest Xilinx Vivado (2014.2)?

I used a simple "Hello, world." OpenCL program in the version 2014.2 Xilinx Vivado IDE, which declared its OpenCL support. One of the code snippets is as follows:
#include <CL/opencl.h>
...
// Connect to a compute device
//
int gpu = 1;
err = clGetDeviceIDs(NULL, gpu ? CL_DEVICE_TYPE_GPU : CL_DEVICE_TYPE_CPU, 1, &device_id, NULL);
if (err != CL_SUCCESS)
{
printf("Error: Failed to create a device group!\n");
return EXIT_FAILURE;
}
However, it seems that this Vivado couldn't recognize the header "CL/opencl.h" and the cl related functions. I resolved the header problem by manually put a external CL directory (derived from CUDA SDK) in my current Vivado HLS project, but it still reported errors like "function 'clGetDeviceIDs' has no function body".
#include <CL/opencl.h> is how it's done on Mac OS X, but on Windows it is usually #include <CL/cl.h>. Have you located your CL include folder? Have you told the IDE where it is? It sounds like your second problem (after you worked around the first) is that you're not linking against OpenCL.lib (or whatever the library extension is on your platform). You need to locate that too and link to it. On an ICD-supporting platform, the Khronos lib can be used and it dynamically locates the installed drivers, but on your platform it is probably be different, so consult the Xilinx instructions.
It seems that including clc.h in my Vivado 2015.2 did the trick.

Linking issue with (Intel SDK) OpenCL and Code::Blocks

I was trying to get my problem solved for hours, but I did not find any usefull hints. Hopefully you guys can help me out:
Some usefull data:
OS: Windows 8 Basic 64bit
Library: Intel OpenCL SDK
Compiler: MinGW(-gcc) (latest version)
IDE: Code::Blocks (latest version)
Minimal not working Code:
#include <stdlib.h>
#include <CL/cl.h>
int main(void)
{
cl_uint available;
cl_platform_id* platforms = (cl_platform_id*)malloc(sizeof(cl_platform_id));
cl_int result = clGetPlatformIDs(1, platforms, &available);
free(platforms);
if(result == CL_SUCCESS)
return 0;
return -1;
}
Code::Blocks Global Compiler Settings:
Linker Settings: Added path to Intel's OpenCL.lib ([...]\Intel\OpenCL SDK\3.0\lib\x64\OpenCL.lib) (tried -lOpenCL as Other Options as well)
Search-Directories for Compiler: Path to Intels OpenCL-SDK include directory ([...]\Intel\OpenCL SDK\3.0\include)
Search-Directories for Linker: Path to Intels OpenCL-Lib directory ([...]\Intel\OpenCL SDK\3.0\lib\x64)
Build-Log:
mingw32-g++.exe -L"[...]\Intel\OpenCL SDK\3.0\lib\x64" -o bin\Release\openCLTest.exe obj\Release\main.o -s "[...]\Intel\OpenCL SDK\3.0\lib\x64\OpenCL.lib"
obj\Release\main.o:main.c:(.text.startup+0x39): undefined reference to `clGetPlatformIDs#12'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings (0 minutes, 0 seconds)
I do not know why he does not link properly.
The [...] in the text is modified by me to shorten the path, normally it would be "C:\Program Files (x86)...".
Hopefully you guys can help me! It is really frustrating! :(
Do you need more information?
EDIT:
Okay... one additional hour and I solved my own problem.
Hope this hint can help some other ppl:
I had to link additionally against the x86-library (seems that some functions are not implemented in X64).
Good to know -.-'''
I got the same problem and I tried hard to figure out the solution and finally I did :)
First of all my hardware are Intel Processor Intel(R) Core(TM) i5-2500 CPU # 3.30GHz and Intel(R) HD Graphics then I installed Intel OpenCL SDK 1.2 after updating the drivers. After that I configure the code::blocks to the new paths for include folder and lib folder as mentioned on the following link: http://www.obellianne.fr/alexandre/tutorials/OpenCL/tuto_opencl_codeblocks.php
Then I tried to compile the examples and I got linking problem as follows:
opencl.o(.text+0x6f):opencl.c: undefined reference to `clGetPlatformIDs#12'
opencl.o(.text+0xa7):opencl.c: undefined reference to `clGetDeviceIDs#24'
opencl.o(.text+0x142):opencl.c: undefined reference to `clGetDeviceInfo#20'
opencl.o(.text+0x263):opencl.c: undefined reference to `clGetDeviceInfo#20'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
4 errors, 0 warnings (0 minutes, 0 seconds)
I tried to use command line and I got the same error then I tried to uninstall Intel sdk and replace it with AMD sdk 2.8 which is support X86 CPU with SSE (Streaming SIMD Extension which is designed by Intel ) 2.x orlater
http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/system-requirements-driver-compatibility/
Finally it works :)
I hope you find this comment useful.
According to an external source i stumbled upon along my own path of enlightenment to this problem i found out something is actually wrong with the mingw-w64 linker. mingw-w64's ld.exe does not want to link with the standard libopencl.a.. whether this is intel SDK specific or not im not sure but here is the link to the solution.
http://sourceforge.net/p/mingw-w64/support-requests/46/
you just have to link to the supplied libopencl.a instead of the default one.
still dont know exactly why the linker gives a problem but i have verified that the solution does (some how) solve the problem.

Is it possible to debug core file generated by a executable compiled without gdb flag?

Is it possible to debug core file generated by a executable compiled without gdb flag ?
If yes, any pointers or tutorials on it ?
Yes you can. It will not be easy though. I will give you an example.
Lets say that I have the following program called foo.c:
main()
{
*((char *) 0) = '\0';
}
I'll compile it and make sure that there is no symbols:
$ cc foo.c
$ strip a.out
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
Ok, time to run it:
$ ./a.out
Segmentation fault (core dumped)
Oops. There seems to be a bug. Let's start a debugger:
$ gdb ./a.out core
[..]
Reading symbols from /tmp/a.out...(no debugging symbols found)...done.
[..]
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804839c in ?? ()
(gdb) bt
#0 0x0804839c in ?? ()
#1 0xb7724e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#2 0x08048301 in ?? ()
Hmm, looks bad. No symbols. Can we figure out what happened?
(gdb) x/i $eip
=> 0x804839c: movb $0x0,(%eax)
Looks like it tried to store a byte with a value of zero to the memory location pointed by the EAX register. Why did it fail?
(gdb) p $eax
$1 = 0
(gdb)
It failed because the EAX register is pointing to a memory address zero and it tried to store a byte at that address. Oops!
Unfortunately I do not have pointers to any good tutorials. Searching for "gdb reverse engineering" gives some links which have potentially helpful bits and pieces.
Update:
I noticed the comment that this is about debugging a core dump at a customer. When you ship stripped binaries to a customer, you should always keep a debug version of that binary.
I would recommend not stripping and even giving the source code though. All code that I write goes to a customer with the source code. I have been on the customer side too many times facing an incompetent vendor which has shipped a broken piece of software but does not know how to fix it. It sucks.
This seems to be actually a duplicate of this question:
Debug core file with no symbols
There is some additional info there.
Yes, you can,
this is what people who i.e. write cracks are doing,
unfortunately i don't have the slides and documents of a course i followed at university anymore, but googling for reverse engineering or disassembly tutorials will give you some starting points. Also knowing your way around in assembly code is essential.
Our class was based on a book mainly chapter 1 & 3 but there is a new edition out now
Computer Systems: A programmer's perspective by R.E. Bryant and D.R. O'Hallaron
which explains the basics behind computer systems and also gives you good knowledge of the working of programs in systems.
Also when learning this be aware that 64bit cpus have different assembly code than 32bit cpu's, just in case.
If the program is compiled without -g flag,you cannot debug core file.
Otherwise you can do so as:
gdb executable corefile
More you can find at:
http://wwwpub.zih.tu-dresden.de/~mlieber/practical_debugging/04_gdb.pdf

Resources