Cache': Отладка callout-модуля

Callout-модуль для Cache' для Win32 представляет собой dll, которая динамически подгружается процессом Cache'. Для проведения отладки dll нужно предпринять необходимые действия:

• Использовать средства разработки, содержащие отладчик dll. В примере используется Borland C++ Builder 5.
• Собрать dll с отладочной информацией.
• Оговорить правила размещения dll.
• Вызвать хост-процесс из-под отладчика.

Из приведенных пунктов вызвать какие-либо затруднения могут только последние два, остальные достаточно очевидны. Продемонстрирую на примере проекта для Borland C++ Builder как именно решить возникшие вопросы.

Правила размещения dll.

Процесс Cache' может использовать два правила размещения dll. Это 1) указанием только имени файла без указания его каталога и 2) указанием полного имени.

Первый способ использует поиск dll начиная с текущего каталога процесса cache.exe. При его использовании следует разместить dll в каталоге где находится файл cache.dat. В случае использования удаленного неймспейса используется каталог /mgr/: процесс запускается на указанном хост-компьютере, но использует данные из удаленной области. Это соглашение, на мой взгляд, наиболее неудобное, поскольку требует размещать (и впоследствии обновлять версии) dll в каждом каталоге, где предполагается использовать callout модуль. Программно использовать его наиболее просто - в рутине пишется только имя файла.

Второй способ использует явное указание полного пути к файлу dll. В этом случае в рутине указывается полный путь, и, возможно, с автоматическим определением положения текущей инсталляции cache. Сам файл dll может быть размещен в любом доступном для чтения месте. В целях повышения производительности его лучше размещать на локальном физическом диске. В своих разработках я использую размещение dll в каталоге /bin/ инсталляции cache.

Правила размещения dll кроме кода вызова в рутине также должны быть описаны в проекте среды разработки. Мы указываем в опциях проекта, где именно должен быть размещен итоговый файл проекта, в каком именно каталоге. Это необязательно может быть каталог по умолчанию. Нужно помнить, что именно в указанный каталог линкер будет выкладывать итоговую dll, что этот каталог должен быть доступен на запись, и что именно этот файл будет использоваться отладчиком, и именно этот файл будет грузиться процессом cache.exe. Также отметим, что если файл dll загружен процессом cache.exe то он не может быть пересобран средой разработки - следует либо выгрузить dll явно, либо завершить процесс - тогда операционная система выгрузит dll автоматически.

Вызов хост-процесса из-под отладчика

Отладка dll производится по правилам, оговоренным в документации на средства разработки. При использовании Borland C++ Builder нужно указать в опциях проекта (меню Run | Parameters) какой исполняемый модуль следует запускать. Здесь следует указать

• Какой exe следует запустить
• С какими параметрами

В качестве хост-программы указываем используемый нами cache.exe с указанием полного пути. В качестве параметров указываем где он должен будет брать информацию о конфигурации текущей инсталляции - ключ -s. В моем случае этот диалог выглядит таким образом:

Если все пути соответствуют действительности и dll собрана с отладочной информацией, то можно запускать проект из-под среды разработки. При этом должен запуститься процесс cache в консольном режиме и перейти в область по умолчанию. Обычно область по умолчанию - это USER.

В появившейся консольной программе работает процесс запущенный как есть. Для загрузки dll следует либо явно набрать команды загрузки, либо вызвать специально составленную для этого рутину. В своих разработках я использую второй вариант как более удобный. Например, для тестирования и отладки составляется специальная рутина с короткой меткой входа без параметров, которая внутри вызывает требующиеся операции. После запуска процесса остается лишь набрать в консольном окне несколько символов.

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