udis86 with ssse3 & sse4

а вот например как всем известно последняя версия udis86 не поддерживает ssse3 & sse4 совершенно официально
Первая моя наивная попытка добавить их самостоятельно провалилась с позором. Например пишем в x86optable.xml скажем для psignb что-нть такое:

<instruction mnemonic="psignb">
  <opcode> aso rexr rexx rexb ; sse66 0f 38 08 ; V W </opcode>
  <opcode> aso rexr rexx rexb ; 0f 38 08 ; P Q </opcode>
</instruction>

компилируем и смотрим itab.c
И например видим что дескрипторы для инструкции попали в таблицы ud_itab_entry itab__0f & itab__pfx_sse66__0f

Впрочем такой вариант тоже не работает:

<instruction mnemonic="psignb">
  <opcode> aso rexr rexx rexb ; sse66 0f sse38 08 ; V W </opcode>
  <opcode> aso rexr rexx rexb ; 0f sse38 08 ; P Q </opcode>
</instruction>


Похоже что текущая реализация opgen.py не поддерживает opcodes длиннее 3х байт. Добавить же нужно следующие инструкции

xbyak

заюзал сегодня кодогенератор с совершенно непроизносимым именем от епонцев
умеет 32 & 64 бита и полный фарш - mmx/sse/sse2/sse3/ssse3/sse4/avx - под linux/mingw/vs2008/vs2010
вроде даже работает, несмотря на FPU (partially)

Update: опыты показали также что ему неизвестны инструкции invept, invvpid, movbe и AMD-V Virtualization ISA Extension

γ version

например
archive password: almostWorks
β тут
Добавлены три опции:

• -mods - печатать список модулей per process
• -dump_patched - скинуть на диск секции отпатченных модулей ядра
• -kdmask - показать маски KD

Были пофикшены

• баг в парзере PE файлов - огромное спасибо sen
• новая версия udis86
• для угнанных exported symbols иногда показывает кто их перехватил
• имена RPC интерфейсов зачитываются из реестра
• и еще всякое про что вам знать необязательно

сломал голову

как известно под лучшей в мире операционной системой код может быть

• 32 или 64 битным
• ASCII или Unicode

два этих требования совершенно ортогональны. Соотв-но вот например у меня есть такой класс:

template <typename T>
class someclass
{
 public:
   template <typename W> void somefunction(const W* filename);
 private:
   template <typename W> const char *get_format_string(int index) const;
};

Тут все просто и очевидно - первый template задает размерность, второй - сhar или wchar_t. Метод get_format_string зовется из somefunction для получения правильных форматных строк для printf например. Заметьте при этом что сам get_format_string не имеет аргументов типа W и вообще служит исключительно для специализации:

template <typename T>
template <typename W>
void someclass<T>::somefunction(const W *filename)
{
  ...
  // вызываем get_format_string
  printf(get_format_string<W>(FORMAT_INDEX1), args);
}

Это компилируется.
Проблема возникает при попытке определить частично специализированный метод get_format_string. Например такое не работает:

template <typename T>
template <>
const char *someclass<T>::get_format_string<char>() const

при компиляции возникает ошибка C2768
И как же будет правильно специализировать такой метод шаблонного класса ?

Update: гугл говорит нам что "частичная специализация шаблонной функции шаблонного класса в чистом виде невозможна" и предлагает использовать костыли в виде traits и прочую boostоподобную упячку. Реальность однако подсказывает что вот такой код, вставленный внутри определения класса, вполне даже работает:

template <typename W>
 const char *get_format_string(int index) const;
template <>
 const char *get_format_string<wchar_t>(int index) const
{
// тело специализированного метода например
}

vs2008 есличо
У меня есть подозрения что главная гордость с++ - шаблоны - на самом деле реализованы в нем крайне через жопу анус мертвого страуса

patched udis86

пока отдельные альтернативно-одаренные граждане ждут "форка на github чтобы может быть присоединиться" (бгг) я выложил все что накорябал в udis86 на проклятый sourceforge например
Изменений не особо дофига:
добавлены opcodes для

• getsec
• paddd
• popcnt
• vmlaunch
• vmread
• vmwrite
• xgetbv
• xsetbv
• xrstor
• xsave

Исправлен баг 2899373

Для добавления ssse3/sse4 нужно править схему декодера, который в настоящее время не поддерживает 4х байтные opcodes, что довольно долго и ресурсоемко (особенно верификация добавленного)

И да - на сайте udis86 творится полный бардак. Например вот этот xml местами не соответствует docs/x86optable.xml

LFENCE vs XRSTOR

а вот например правя сегодня во все дыры udis86 наткнулся на чудесное:
lfence - 0F AE /5
xrstor - 0F AE /5
кажется от нас что-то скрывают (c)

Update: в доке от Intel сказано ровно то же самое. Опыты однако показали что правильно должно быть примерно так:
lfence - 0F AE /5 /mod=11 с любым /rm. Итого этой инструкции 8 различных opcodes
xrstor - 0F AE /5 /mod=!11
почему mod не должен быть равен 11 я так и не вкурил, но иначе оно не работает

god hate us all

а вот например давеча я используя udis86 нарвался на некий файлик, содержащий инструкцию paddd (которая содержится в MMX и якобы должна поддерживаться. Однако же...). Далее последовало внимательное и поучительное разглядывание bug tracker
Судя по всему проект мертв, ибо ни единого бага с сентября 2009 года не было пофикшено. Более того - ssse3/sse4/AES instructions не поддерживаются официально
Несколько подумав полез смотреть другие движки дизассемблера. Требования очень просты - должен собираться под 32/64 бита под windows/linux, в user mode & kernel mode, имена opcodes должны быть легко отключаемы (для экономии места в драйвере например)
Резко стало еще грустнее

• BeaEngine - полная упячка
• diStorm - BSD лицензия канешно сильно лучше чем GPL, но файл include/mnemonics.h повергает в адское уныние
• Mediana - кодировать имена мнемоник в общей с парзером инструкций таблице - полный crap

Остальное даже не решился посмотреть
Проще всего самому добавить/пофиксить все что нужно в том же udis86 чем найти то что требуется на самом деле. Хотя канешно добавление пары семейств команд будет довольно ресурсоемким занятием

PS: добавление инструкции paddd потребовало ровно 4 строчки и установки петона под винду

Список opcodes, не поддерживаемых текущей версией udis86 (из тех что я нашел)