Честно говоря, я впервые использую какую-либо библиотеку, например Yeppp !, и под этим я подразумеваю SIMD-библиотеки с динамическим выбором времени выполнения, или как бы они это ни называли. Конечным результатом является то, что библиотека должна выбирать оптимальный код сборки SIMD для запуска на любой платформе и на каком оборудовании она работает.
Это казалось отличным инструментом для использования в моем проекте, однако, как говорится в заголовке, я не могу назвать ни одного Yeppp! функция без возникновения ошибки сегментации. Отладочная информация, которую я смог получить, тоже не очень помогает.
Моя конфигурация системы:
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
Я перечисляю процессор и тому подобное, потому что это может быть важно для Yeppp! выбирает правильное время выполнения, которое может быть проблемой.
Ниже приведен простой тестовый код, который я использую, хотя я пробовал другой Yeppp! функции с различными типами данных, это была все та же ошибка сегментации. Я также пробовал различные выравнивания, такие как 32 и 64, но я сомневаюсь, что это проблема.
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 );
Я не собираю его с какими-либо специальными флагами или чем-то подобным, поэтому -m32 или 64. Я тоже пробовал то же самое в C, с теми же результатами и в основном идентичными сборками, так что это не язык.
Я ссылаюсь на двоичный файл Linux x86_64 libyeppp.so, поставляемый с Yeppp! дистрибутив, так как я использую 64-битную платформу, и это единственная версия, которую GCC принимает.
Разборка звонка это:
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>
Который выглядит довольно стандартно.
Однако при входе в функцию я получаю:
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
Который затем, идя вперед несколько инструкций к jmp 0x4013d0
после выполнения этого GDB дает мне
0 No function contains specified address.
Затем следующая инструкция, если она есть и она не пытается выполнить значение NULL, приводит к ошибке сегментации. Это примерно так, как я смог получить. После нескольких попыток, он пытается открыть ../sysdeps/x86_64/dl-trampoline.S
файл, который он не мог найти.
Я в значительной степени зашел в тупик относительно того, почему он сделал бы это, если бы Yeppp! сам по себе неисправен. Начиная с версии 1.0 Yeppp! библиотеке всего несколько дней, я не смог найти никого с похожей проблемой или какими-либо проблемами вообще.
PS: я впервые за долгое время публично задал вопрос о программировании, поэтому, если понадобится дополнительная информация, чтобы помочь решить эту проблему, я с радостью предоставлю ее.
Вам нужно позвонить yepLibrary_Init()
перед использованием библиотеки (и yepLibrary_Release()
после того, как вы закончите с этим). Эта функция обнаруживает микроархитектуру ЦП и наборы команд и инициализирует внутренние указатели (которые изначально являются нулевыми — вот почему вы получаете segfault).
Других решений пока нет …