Посовeтуйте отладчик

У меня остро стоит потребность в отладчике, но мне нужно что-нибудь, что может напрямую работать с исходным кодом. Чтоб косяки можно было бы вылавливать быстро и на лету. Просто, когда я кидаю свою программку в Ollydbg, то в том как дезассемблирует довольно муторно и тяжело узнавать свою программу.

Знаком ли кто с такими оттладчиками?

Да. пишу я на masm.


Спасибо.

 

Попробуй в link.exe использовать опцию /DEBUG

 

И что это должно дать?

 

lust
метки и структуры, ну и переменные в отладчике поддерживающем pdb!
Удачи!

 

Спасибо!
Только ещё пара вопросов, что есть pdb?
Какой отладчик из тебе знакомый pdb поддерживает?

 

OllyDbg может быть отладчиком уровня исходного кода, правда у меня был проект на С++ и OllyDbg сопоставлял дизассемблированный кусок программы с её исходным кодом в проекте, в данной точке.

тоесть вот так:

Код (Text):

1. 00401A3E   .  E8 4B120000   CALL <JMP.&vcl100.@Forms@TApplication@Ru>
2.  
3.  
4. 00402C8E=<JMP.&vcl100.@Forms@TApplication@Run$qqrv>
5. Project3.cpp:15.  Application->Run();

 

lust
PDB (program database) - формат отладочной информации. Оля его поддерживает. Если линкеру дать ключ /DEBUG, (а до этого компилятору ключ - /Zi), то он линкер сформирует PDB файл, а в EXE укажет путь к нему (если пути нет, то отладчик ищет файл по пути с EXE файлом и с именем равным базовому имени с расширением PDB). Потом для верности кидай PDB файл в папку с отлаживаемой программой, и сможешь видеть в Олли символы определенные в исходнике - имена меток(процедур), переменных, номера строк. Чтобы увидеть все символы в Олли, нажми Ctrl + N в контекстном меню дизассемблера. В появившейся таблице, записи с типом Library и будут символами из PDB файла. Кстати при исследовании системных библиотек действуют теже механизмы - качаем PDB файл например к KERNEL32.DLL, кидаем его в туже папку и видим символы системных DLL. Надо именно копировать, у меня фича с переменной _NT_SYMBOL_PATH не пашет и оля не видит PDB файлы указанные по этому пути.

 

jCronuz
MASM не может генерить отладочную инфу, где указывается исходный код.

 

Спасибо за инструкцию, но проблема в том, что когда я жму Ctrl+N выскакивает окошко Names in ntdll и там у всех записей тип Export и с кодом исходным там ничего общего нет =(

Что может быть не так?
спасибо.

 

lust

Судя по твоим словам, ты стоишь в ntdll.dll - для нее с PDB ты увидишь только имена вызываемых функций и имена входов, ну и еще что-то, но никак не свой исходник. Если мой склероз не врет, у микрософта есть специальная версия ХП(или основных DLL) - для отладки. Вот там может будет поподробнее что-то.
Короче, сначала пойми что ты делаешь, а потом удивляйся

 

lust
Ты это, выбери свой модуль через View - Executable Modules (ALT+E).
После этого по CTRL+N будут отображаться имена для твоего exe.

 

У Микрософта есть специальные PDB для всех системных DLL. Чтоб их скачать, нужно windbg (или cdb/ntsd) и настройка Symbol Server: http://msdn.microsoft.com/en-us/library/cc266473.aspx

 

Только час искал, но не смог найти: есть ли symbol server plug-in для ollydbg? т.е. чтоб автоматом символы качал

 

хз, я сливаю обычно WInDbg через чтото типа такого

!sympath srv*D:\Symbols*http://msdl.microsoft.com/download/symbols

 

comrade
Я про эти символы и говорю. Я их качал и действительно в отладчике тогда все гораздо понятнее
выглядит - особенно ntdll. Просто я смотрел каталог, не помню уж где, и там кроме PDB для обычных 2000-го и ХП, были PDB для 2000free(никогда не видел эту ОС) и по-моему(говорю что не уверен) версия chk. Сами DLL версии chk толще обычных. Но говорю склероз, т.ч. может и почудилось.
А для закачки удобнее SymbolRetriever (по моему из Driver Studio). Просто им можно заказать для конкретной DLL, которая даже не подгружена. Можно и в альтернативном формате для SoftIce - это большой плюс.

 

2000fre - это "release" билд винды (тоесть с оптимизациами, и т.д.)
chk - это "debug" билд (без оптипизаций, с ASSERT'ами, и т.д.). это удобно для разработчиков драйверов - если они что то сделают не правильно в ядре, то винда выкинеть ASSERT -> KeBugCheck -> BSOD

Есть еще ютилита symchk - толи от Руссиновича, то ли внутри Debugging Tools for Windows, которая по описанию SymbolRetriever, вроде делает идентичное.

А насчет плагина для Ольки, а говорил про автоматическую (on-demand) загрузки символов - так же как делает windbg. Вроде такого плагина не существует

 

lust

Чтобы слить PDB файл для конкретного файла DLL юзай либо из Syser Debugger прогу, которая наывается Syser Symbol Receiver. В ней указываешь файл, для которого нужны символы, и папку куда положить скаченные символы. Также можно юзать программу Symbol Type Viewer, которая почти идентичная проге, которая идет в комплекте от Syser. Вот линк - http://www.syseclabs.com/software/SymbolTypeViewer_v1.0_beta.zip
А теперь по шагам инструкция как все таки сделать чтобы OllyDebug увидела твои символы, например для NTDLL:

1) Скачиваем последнюю версию Microsoft Debugging Tools отсюда - http://www.microsoft.com/whdc/devtools/debugging/default.mspx
2) Устанавливаем их.
3) Идем в папку инсталяции Debugging Tools и копируем с заменой все *.DLL файлы в папку с Олли.
4) Точно также копируем эти же файлы в папку с программой, которую ты выбрал для скачивания PDB-файлов.
5) Скачиваем символы.
6) Скаченный NTDLL.PDB кидаем в папку с NTDLL.DLL.
7) Запускаем Олли и видем отладочные символы.

 

Osen

А разве lust хочет символы в ntdll увидеть. Он хочет увидеть исходник на ассемблере, как
это бывает в нормальных отладчиках : Visual Studio или Дельфи
Такого нет по простой причине : никому не нужен "реальный" исходник где invoke и т.п. расписаны
по командам, т.к. дизасм не хуже и не требует дополнительного файла PDB. Олли, если правильно настроить, все invoke достаточно грамотно показывает, к сожалению имена она из PDB криво извлекает - у меня получилось показывать только половину в лучшем случае. Ключ masm /Zf делает все локальные паблик.
=======================
А проблема у lust IMHO простая, новичковская. Он при отладке провалился или стоит при аттаче в ntdll и не может найти свои операторы. Ждем что он скажет.

 

valterg
NTDLL я привел для примера, в случае с отладочной информацией из его EXE механизм в точности соответствует. Насчет того, что никому не нужен реальный исходник, когда пишешь на ассемблере, это небольшая глупость, т.к. вполне очевидно, что это может явно упростить отладку, т.к. очень часто применяют макросы, и чем меньше кода в охвате взляда - тем лучше - не отвлекаешься на лишнюю информацию. Я был бы очень рад, если бы FASM генерил PDB-файл. Насчет того, что у тебя Олли криво имена извлекает надо немножко выучить матчасть, я же не просто так распинался по поводу подгрузки PDB-символов. DLL, для работы с PDB-файлами должна соответствовать самому PDB-файлу, поэтому скачай Debugging Tools For Windows и кинь нужные DLL в папку с Olly. А причина проста - Olly сама не работает с PDB, т.к. он оффициально не документирован, при этом Micro$oft поставляет обновленные DLL для работы с этим форматом.

lust
Если Olly не видит символы для твоего EXE, значит надо засунуть PDB-файл к EXE-файлу, и проверь что ссылки на исходный код в PDB-файле валидны. Ведь с твоим EXE-файлом все точно также, что и с символьной информацией для NTDLL.DLL.

Забавно отметить то, что PDB-файлы, которые мы скачиваем с серверов Micro$oft делаются с ключом линкера /Zd, который добавляет только глобальные символы, внешние символы и номера строк, но при этом ссылка на соответствующий исходный файл в таких PDB отстствует.

 

Компили с ключами:
ML.EXE /c /coff /Cp /Zi /Zd /Zf

Собирай так:
LINK.EXE /SUBSYSTEM:WINDOWS /VERSION:4.0 /DEBUG

В ОЛЬКЕ нужно настроить.
в меню Debugging options -> (зкладка) CPU -> Synchronize source with CPU (тут поставь галочку).

Когда запустишь прогу заходи в меню View -> Source files
там находишь свой исходник и ...

Ставишь бряк там где тебе хочеться F2 (на своем исходнике) и запускай свою прогу F9.
Если находишься не в своем процессе (системная ЛИБА или ...) нажми Alt+F9 и вернешся в свой процесс.

Удачи.