Отслеживание зависимости, которая содержит инструкции SSE - PullRequest
3 голосов
/ 16 мая 2011

Один из наших клиентов нуждается в сборке нашей программы без SSE, поскольку он работает на довольно старом оборудовании. Моя проблема в том, что даже если я изменю настройки нашего проекта по всем направлениям, чтобы сбросить SSE для всех библиотек и двоичных файлов, может показаться, что где-то все еще существует зависимость, которая компилируется с инструкциями SSE, что приводит к сбою приложения.

Мои вопросы: есть ли способ взять двоичный файл или библиотеку и определить, содержит ли он инструкции SSE определенной версии SSE или нет?

Мы используем VS и язык C ++, поэтому любой инструмент, применимый к этому набору инструментов, будет потрясающим.

Ответы [ 3 ]

4 голосов
/ 16 мая 2011

Разберите все задействованные двоичные файлы, затем выполните поиск мнемоники инструкций SSE в разборках.

1 голос
/ 16 мая 2011

Поскольку вы уже отключили генерацию инструкций SSE в компиляторе, проблема в одной из статических библиотек.Чтобы сузить его, в основном у вас есть 2 пути:

  1. Разберите файлы .lib или .obj, на которые вы ссылаетесь.На самом деле это не простое решение, если у вас нет доступа к специализированным инструментам.Как правило, дизассемблирование - это очень сложный процесс, так как инструмент должен выяснить все пути выполнения в коде, фактически не запуская его.Это делает это, чтобы отделить данные от кода.Лучший инструмент для таких задач - IDA Pro .После разборки вы можете искать инструкции SSE, либо написав макрос в IDA Pro, либо экспортировав результаты в текстовые файлы и просто используя grep.
  2. Более простой подход - запустить программу и выяснить, где она дает сбой.Для продолжения вам понадобятся две вещи: выяснение адреса инструкции, которая вызывает сбой, и «файла карты», чтобы выяснить, где он находится.Последнее очень просто: в Visual studio вы должны установить параметры отладчика компилятора и компоновщика для создания файла карты.Этот файл в основном скажет вам адрес всех и всех функций в исполняемом файле.Найти адрес сбоя обычно легко, так как Windows предложит вам и скажет что-то вроде Ошибка приложения Инструкция по адресу "0x635de077" ... .Вы используете этот адрес и посмотрите на файл карты, чтобы увидеть, к какой функции он принадлежит.Кроме того, вы можете запустить программу внутри отладчика.Когда происходит сбой программы, отладчик показывает, где она остановилась.

edit: Еще один метод для разборки .lib-файлов заключается в использовании утилиты DUMPBIN , которая поставляется сVisual Studio.Кроме того, метод мини-дамп, предложенный STATUS_ACCESS_DENIED, является отличной идеей.

0 голосов
/ 16 мая 2011

Используйте метод, описанный здесь , чтобы получить файл мини-дамп от клиента. То есть Попросите клиента запустить вашу сборку. После сбоя необходимо создать файл минидампа, и вы можете использовать его - после смерти - для точного анализа места его падения. Который, вместе с символами отладки (и / или файлом карты), фактически скажет вам точную библиотеку, которая вызвала хаос.

Это сводится к точке 2 в решении, предложенном AlefSin. Однако клиенту не придется запускать отладчик. Для драйверов режима ядра это, как правило, единственное средство получить значимую информацию о проблемах. Однако такая же возможность существует для кода режима пользователя. Используйте это.

...