Segmentation fault on any Yeppp! api call

Question

To be honest, it's my first time using any sort of library like Yeppp!, and by that I mean SIMD libraries with dynamic runtime selection, or however they would word it. End result is that the library is supposed to choose the optimal SIMD assembly code to run on whichever platform and hardware it is being run on.

This seemed like a great tool to use in a project of mine, however, as the title states, I cannot call any Yeppp! function without a segmentation fault occurring. The debugging info I've been able to get doesn't really help, either.

My system configuration is:

Xubuntu 13.04 'raring' with Linux 3.8.0-31-generic x86_64

GCC 4.8.1 --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu .... etc, there were many more, but I chose the important ones

Code::Blocks IDE and GDB 7.5.91.20130417-cvs-ubuntu debugger through Code::Blocks

Intel Pentium(R) Dual-Core CPU T4400 @ 2.20GHz with SIMD instruction sets MMX, SSE, SSE2, SSSE3

I list the CPU and such because it may be important to how Yeppp! selects the correct runtime, which may be the issue.

Below is the simple test code I am using, though I tried other Yeppp! functions with various data types, it was all the same segmentation fault. I've also tried various alignments like 32 and 64 too, but I doubt that is the issue.

YEP_ALIGN(16) int32_t a[100], b[100], c[100];
//just test values
for( int x = 0; x < 100; x++ ) {
    a[x] = x + 1;
    b[x] = x - 1;
}

yepCore_Add_V32sV32s_V32s( a, b, c, 100 );

I'm not compiling it with any special flags or anything, so no -m32 or 64. I've tried the same thing in C, too, with the same results and basically identical assemblies, so it's not language.

I link against the Linux x86_64 libyeppp.so binary provided with the Yeppp! distribution, since I'm running a 64-bit platform, and it's the only one GCC even accepts.

The call disassembly is:

0x40179a    lea    rdx,[rbp-0x1a0]
0x4017a1    lea    rsi,[rbp-0x330]
0x4017a8    lea    rax,[rbp-0x4c0]
0x4017af    mov    ecx,0x64
0x4017b4    mov    rdi,rax
0x4017b7    call   0x401550 <yepCore_Add_V32sV32s_V32s@plt>

Which looks pretty standard. However, when stepping into the function I get:

0x401550    jmp    QWORD PTR [rip+0x205b7a]        # 0x6070d0 <[email protected]>
0x401556    push   0x17
0x40155b    jmp    0x4013d0
0x401550    jmp    QWORD PTR [rip+0x205b7a]        # 0x6070d0 <[email protected]>
0x401556    push   0x17
0x40155b    jmp    0x4013d0

Which then, going forward a few instructions to the jmp 0x4013d0, after executing that GDB gives me

0   No function contains specified address.

Then the next instruction, assuming there is one and it doesn't try to run at NULL, leads to the segmentation fault. That's about as far as I've been able to get. After a few times of tweaking with it, it attempts to open a ../sysdeps/x86_64/dl-trampoline.S file, which it couldn't find.

I'm pretty much at a dead end as to why it would do this, unless Yeppp! itself is faulty. Since the 1.0 release of the Yeppp! library is only a few days old, I haven't been able to find anyone with a similar issue or any issues at all.

PS: this is the first time in a long while I've publically asked a question on programming, so if any further information is needed to help solve this, I'll happily provide it.

Answer 1

You need to call yepLibrary_Init() before using the library (and yepLibrary_Release() after you finish with it). This function detects the CPU microarchitecture and instruction sets and initialises the internal pointers (which are initially null - that is why you get segfault).