вторник, 7 сентября 2010 г.

profiler-driven linker

навеяло тут чтением всяких разных умных книжек
Вот например у нас есть некая прога и мы хотим выжать из нее максимум производительности кисонька, еще капельку. Как известно у современных процессоров есть кэш, код из которого исполняется на порядок быстрее, чем из RAM. Можно было бы собрать профайлером граф вызовов функций, найти в нем самые тесно (по числу вызовов во время тестовых прогонов) связанные подграфы, и подсунуть эту информацию линкеру для генерации окончательной версии программы, чтобы он сложил эти функции рядом. Тогда при исполнении они скорее всего попадут в кэш все сразу, что должно дать некоторый profit в виде довольно ощутимого прироста производительности. Можно кстати аналогичный трюк исполнить и со статическими данными программы.
Более того, поскольку у разных процессоров даже того же Intel размер кэша отличается - линкер мог бы заточить прогу под конкретно наш процессор

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

Update: все украдено придумано до нас - visual studio 2005 умеет делать практически вышеописанные действия под именем profile-guided optimization:
Block Layout. In this optimization, we form the hottest paths through a function, and lay them out such that hot paths are spatially located closer together. This can increase the utilization of the instruction cache and decrease the working set size and number of pages used.

воскресенье, 5 сентября 2010 г.

patched pdbdump

залил на sourceforge сорцы обточенного грубым рашпилем pdbdump
Хотя оригинал и не обновляется уже 8 лет - у него правильная BSD-style license, так что его можно править для всяких своих целей невозбранно.
Я правда уже и не особо помню, что именно там пофиксил - добавил в PdbRender.cpp регистров от amd-64 и еще была пара мест где он у меня падал на всяких разных странных pdb - вроде бы уже не падает :-)
Еще для линковки либы от dia sdk больше не нужны - функция NoRegCoCreate коряво реализована в rp.cpp
Проект для visual studio 2005 прилагается

суббота, 4 сентября 2010 г.

fltmgr.sys 64bit exports

Должен признаться что в предыдущем посте я несколько ошибся - у fltmgr.sys есть механизмы для enumeration (просто я их ни разу не использовал). Нужно смотреть правда насколько сложно их пропатчить/обмануть

руткиты под windows x64

прочитал тут наконец (я.тормоз) про tdl4
много нервно курил думал
Насколько я понимаю самым большим препятствием к распространению subj был именно запрет на загрузку неподписанных драйверов. После его обхода виста и windows 7 представляют собой отличное благоустроенное гнездо для проживание всякого с блэкджеком и шлюхами. Мы конечно помним про patch guard, но
  •  во-первых у них всегда есть fltMgr.sys и с написанием фильтра файловой системы справится любой школьник. Значит сокрытие файлов и директорий делается намного проще, чем поддерживать зоопарк версий под 32битные версии windows (на некоторых из них fltMgr.sys например нету)
  •  во-вторых у них всегда есть CmRegisterCallback, про который писал даже детский юмористический журнал ксакеп. Значит сокрытие веток в реестре представляет тривиальную задачу
  •  в-третьих у них всегда есть windows filtering platform. Так что фильтровать и следить за трафиком опять же проще чем под 32битным дурдомом
  • в-четвертых у них всегда есть ObRegisterCallbacks
  • в-пятых все вышеописанное богатство (кроме fltMgr.sys) не предоставляет механизмов даже простой энумерации зарегистрированных драйверов и хуков. грабь воруй убивай - совершенно анонимно с точки зрения windows

пятница, 3 сентября 2010 г.

apisetschema.dll

Если вы когда-нибудь смотрели windows 7, то могли заметить что многие системные .dll имеют очень странные импортированные модули api-MS-Win-Core-XXX.dll, которые хотя и присутствуют в %SystemRoot%\System32 (как hidden files), но кода внутри себя явно не содержат.
Гугл говорит что это извращение было сделано для поддержки мифического режима MinWin, хотя мне эта версия не кажется убедительной. Как бы там ни было, было бы весьма недурно знать, как резолвится импорт на эти модули на самом деле