Рабочая программа получает недопустимую ошибку инструкции на «чистой машине»? - PullRequest
Новая
       9

Рабочая программа получает недопустимую ошибку инструкции на «чистой машине»?

4 голосов
/ 12 февраля 2010

У меня есть программа, которая корректно работает на моей машине для разработки, но выдает ошибку «Недопустимая инструкция» при тестировании на «чистой машине», где скопированы только необходимые файлы.

Программа состоит из моей общей библиотеки, созданной из источников C ++, и примера программы-оболочки C, которая демонстрирует использование библиотек. На машине для разработки все встроено в Eclipse w / g ++, и Debug и Release работают нормально. Ряд стандартных библиотек связаны между собой.

Чтобы проверить зависимости, которые я мог пропустить, я скопировал файл .c, файл .so моей библиотеки и файл .h библиотеки в новую установку Linux и скомпилировал / связал их с помощью простого скрипта, созданного с помощью той же компиляции выпуска параметры, которые использует Eclipse. Обе машины имеют g ++ 4.3.2.

Когда я запускаю программу на чистой машине, она сразу выходит из печати после печати «Недопустимая инструкция».

Запуск в GDB производит: 

(gdb) run
Starting program: /home/sfallows/Source/Apps/MySample/MySample 
[Thread debugging using libthread_db enabled]
[New Thread 0xb5c4ca90 (LWP 7063)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb5c4ca90 (LWP 7063)]
0xb7f0cb29 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/include/c++/4.3/iostream:77
77   static ios_base::Init __ioinit;
Current language:  auto; currently c++
(gdb) bt
#0  0xb7f0cb29 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/include/c++/4.3/iostream:77
#1  0xb7f0cb48 in global constructors keyed to _ZN8NodeLockC2Ev () at ../NodeLock.cpp:194
#2  0xb7f204ad in __do_global_ctors_aux () from /home/sfallows/Source/Apps/MySample/libMyLib.so
#3  0xb7ee5c80 in _init () from /home/sfallows/Source/Apps/MySample/libMyLib.so
#4  0xb7fe1de4 in ?? () from /lib/ld-linux.so.2
#5  0x00000001 in ?? ()
#6  0xbf8e6b74 in ?? ()
#7  0xbf8e6b7c in ?? ()
#8  0x00000007 in ?? ()
#9  0xbf8e6b2c in ?? ()
#10 0x00000001 in ?? ()
#11 0x00000001 in ?? ()
#12 0xb7feeff4 in ?? () from /lib/ld-linux.so.2
#13 0x00000000 in ?? ()
(gdb) Quit

Я не уверен, почему он запускает статические компоновщики в NodeLock.cpp. У меня нет ни статических / глобальных объектов в этом файле, ни статических / глобальных объектов этого класса.

Машина для разработки представляет собой Intel Core2 Quad, а чистая машина - Pentium 4 Dual. Я предполагаю, что по умолчанию в g ++ используется общее подмножество инструкций x86, и разница в процессорах не является моей проблемой.

Любые предложения о том, что еще посмотреть на оценили. Я пытаюсь избежать установки всего исходного кода библиотеки и зависимостей на чистый компьютер.

К ответу rmn и комментарию Джона Бокера: В мире Windows exe и dll работают на множестве процессоров Intel и AMD, поэтому явно существует широко распространенное подмножество инструкций. Я думал, что GCC будет делать то же самое? Думаю, я полностью исследую набор инструкций / варианты архитектуры.

Ответы [ 4 ]

8 голосов
/ 12 февраля 2010

Вы можете попробовать явно скомпилировать для архитектуры i686 (используя опцию -march=i686 для gcc). На всякий случай, если у вас есть некоторые специфичные для Core2 инструкции, сгенерированные вашим компилятором ...

2 голосов
/ 12 февраля 2010

Цитата: «Машина для разработки - это Intel Core2 Quad, а чистая машина - Pentium 4 Dual. Я предполагаю, что по умолчанию в g ++ используется общее подмножество инструкций x86, и разница в процессорах не является моей проблемой».

Я думаю, что это проблема .. Попробуйте либо скомпилировать специально для этой машины, либо пересобрать на чистой машине, либо получить две идентичные машины. - это мои 0,02 $.

Кроме того, похоже, что вы умираете при загрузке ld-linux.so. Возможно версии Linux отличаются?

1 голос
/ 12 февраля 2010

вы умираете при статической инициализации.Порядок выполнения работ зависит от конкретной реализации и может варьироваться в зависимости от версии среды выполнения.Это может быть вашей проблемой.Это одна и та же библиотека libstdc ++ на обеих машинах?

В любом случае, иметь перекрестные зависимости плохо, вам нужно изменить код, если это окажется проблемой

1 голос
/ 12 февраля 2010

Я могу вспомнить пару вещей, которые вы можете попробовать:

  1. Используете ли вы какую-либо оптимизацию, кроме -O3? Может быть, старая система не поддерживает это.
  2. Возможно, вы уже проверили это, но проверяли ли вы md5 двоичного файла в вашей системе по сравнению с целевой системой?
  3. Ваша библиотека выполняет многопоточность? Если это так, поскольку количество ядер отличается, то, возможно, у вас где-то есть состояние гонки
...