Биться об стенку тоже вар)) Если хорошо удариться кодинг вообще не нужен станет   
Создатели EurekaLog заявляют, что используют только стандартную Debug Info.... 
Они же получают имя процедуры.... даже если, она "висит сама по себе"....  
Я в тупике. 

Давайте ещё раз. Приведу кусок текста из своей статьи про исключения:


Формат DCU файлов недокументирован и меняется в (почти) каждой версии Delphi. Очевидно, что пытаться брать отладочную информацию из DCU, как это делает отладчик в Delphi - не самая лучшая идея.

Окей, тогда где её берут?

Ну во-первых, есть две таких опции: "TD32 Debug Info" и "Remote Debug Info" (вкладка "Linker"). Включение опции заставляет компилятор добавить в exe секцию с данными, которые содержат всю отладочную информацию для exe в формате TD32 или удалённого отладчика Delphi. Это уже можно использовать - в частности JclDebug и EurekaLog при недоступности других источников берут информацию именно из отладочной информации для TD32 - см. например TJclDebugInfoTD32.InitializeSource (есть даже целый модуль JclTD32.pas).
Но обычно это является запасным вариантом, а не основным. Почему? Потому что отладочная информация в этих форматах предназначена для внешнего (Turbo Debugger 32) и удалённого отладчика соответвенно. Это значит, что её формат оптимизирован для отладки, но не для ваших целей. В частности, с практической точки зрения это означает многократное (!) увеличение размера exe-файла.

Ещё варианты? Окей, вот основной вариант:

Вот его и используют все готовые решения. Текстовый файл фиксированного формата. Что может быть проще? Читаем его, ищем нужный адрес и смотрим, какой функции, какому классу он принадлежит. 
Разумеется, читать (парсить) файл каждый раз - долго и неудобно (да и большой он). Именно поэтому большинство готовых решений при компиляции берут этот файл, выдёргивают из него нужную информацию, сохраняют её в удобном для себя формате и подключают её к exe-файлу. Получается аналог отладочной информации в формате TD32 в exe, только формат отладочной информации будет ваш личный. Кстати, готовые решения при этом часто ещё сжатие применяют. В среднем прирост размера exe файла составляет где-то 30%.

JclDebug, например, получает информацию о имени функции по заданному адресу с помощью таких классов:
 - TJclDebugInfoMap - получает информацию из map-файла с тем же именем, что и exe-файл.
 - TJclDebugInfoBinary - получает информацию из встроенной в exe секции JCLDEBUG или jdbg-файла с тем же именем, что и exe-файл.
 - TJclDebugInfoTD32 - получает информацию из встроенной в exe секции TD32.
 - TJclDebugInfoSymbols - получает информацию из встроенной в exe секции виндовой отладочной информации - аналог TD32, только решение от Microsoft.
Основным вариантом является TJclDebugInfoBinary, а остальные используются как запасные.

EurekaLog, во-первых, использует JclDebug для получений той же информации:
 - TELDebugInfoMap - получает информацию из map-файла с тем же именем, что и exe-файл.
 - TELDebugInfoJedy - получает информацию из встроенной в exe секции JCLDEBUG или jdbg-файла с тем же именем, что и exe-файл.
 - TELDebugInfoTD32 - получает информацию из встроенной в exe секции TD32.
Плюс добавляет свою информацию - реализация полностью аналогична TJclDebugInfoBinary/TELDebugInfoJedy, только формат не JDBG, а EurekaLog (отдельного класса нет, получение информации лежит леликом внутри GetSourceInfoByAddr). Этот вариант является для неё основным, а остальные используются как запасные.

Т.е. как я и говорил - сама идея проста до безобразия (искать строчки в текстовом файле), но чтобы её реализовать самому.... попотеть придётся.

Спасибо) большое)
Вот. теперь все ясно и понятно...  
Как говориться, дело ясное, что дело темное    Попотеть уж точно придется))
Теперь ударюсь в способы работы с exe файлами)) надо подумать, как дополнить его нужной инфой, но при этом не попортить))

Добавлено через 2 минуты и 17 секунд
Жаль у меня постов мало, а то бы обязательно плюсик поставил, поэому ограничусь человеческим спасибо.
А за столь подробную информацию и нескольких +ов не жаль))) 

Проще всего (и обычно так все и поступают) - добавить в exe файл пользовательский тип ресурса (RCData) с уникальным именем.
Если я не ошибаюсь, то JCL добавляет секцию с именем JCLDEBUG, а EurekaLog - с ELDATA.

P.S.

Кстати, в текущей версии EL есть как минимум три серьёзные проблемы (Fabio пообещался исправить в следующей версии):
1. Используется RAW-метод трассировки. Это значит, что стек вызовов может содержать ложные элементы. По-хорошему нужна возможность использовать frame-based трассировку (на выбор, разумеется).
2. В стеке вызовов не показывается запись, если для неё нет отладочной информации. Видимо, подразумевалось, что это сгладит пункт 1. В реальности это сделало некоторые логи очень тяжело читаемыми. По-хорошему нужно показывать просто адрес без доп. информации.
3. Из map-файлов не забираются записи из модулей, для которых нет отладочной информации (в этом случае в map файле нет информации о строках, но по-крайней мере там есть список функций - вот его бы нужно брать, как это делает JCL). Например, для стандартных модулей (SysUtils и т.п.), если отключена опция "Use Debug DCUs". Это приводит проблемам в совокупности с пунктом 2. 

Лично для себя я вписываю в EL трассировку из JCL и модифицирую парсер. Ну пока это не поправят.

Это сообщение отредактировал(а) CodeMonkey - 13.11.2008, 17:01