Расположение кода в образе

← →
Alkid © (2006-05-15 18:08) [0]

Вопрос по "кишочкам" Дельфи (в частности Dlephi 5) -
если я в классе описаны методы в определённом порядке, то в каком
порядке будут они следовать в двоичном образе сегмента кода, загруженного в память процесса?
Варианты (которые мне пришли в голову):
1. В порядке объявления в заголовке класса.
2. В порядке описания в секции implementation.
3. В каком-то другом порядке.
4. Какого-либо правила нет.

Суть проблемы состоит в том, что бы отследить происхождение одного
мистического обращения к уже уничтоженному объекту. Как вы знаете,
call stack в Дельфи реализован отвратительно (вот где MSVC можно брать за пример).

← →
oldman © (2006-05-15 18:09) [1]

> отследить происхождение одного
> мистического обращения к уже уничтоженному объекту

мдя...

← →
Alkid © (2006-05-15 18:12) [2]

> мдя...

Вот именно, мдя :) Вы никогда не увлекались трассировкой стандартных библиотек Delphi в режиме дизассемблера? Очень советую как средство выжимания мозгов :)

← →
oldman © (2006-05-15 18:14) [3]

> Alkid © (15.05.06 18:12) [2]

Я как-то увлекался русским языком... Очень советую...

← →
oldman © (2006-05-15 18:18) [4]

Кто мешает выставить флаг "объект уничтожен", что бы не было "мистического обращения"?
Кстати, "мистическое обращение" - это что такое???

← →
Alkid © (2006-05-15 18:18) [5]

> Я как-то увлекался русским языком... Очень советую...

Как средство выжимания мозгов? :) Разве что только как хобби, денег мне за это платить не будут, в отличие от программирования.

← →
han_malign © (2006-05-15 18:21) [6]

> Как вы знаете, call stack в Дельфи реализован отвратительно (вот где MSVC
> можно брать за пример).

- если тебе так не нравится fastcall, используй cdecl... А для того чтобы "Дельфи" позаботился о твоем кривом коде, наподобие MSVC, достаточно влючить Compiler->Stack frames, Range checking и Owerflow checking... А адреса, построчно, можно посмотреть в map файле, если включить Linker->Map file->Detailed...
А увлекаться "трассировкой стандартных библиотек Delphi в режиме дизассемблера" - надо со включенным Use Debug DCU, чтобы мозги на место вжать...

← →
Джо © (2006-05-15 18:24) [7]

> 1. В порядке объявления в заголовке класса.

По сабжу. Всегда думал, что 1 "В порядке объявления в заголовке класса".

← →
TUser © (2006-05-15 18:26) [8]

По крайней мере просто процедуры (не методы классов) - в порядке следования в implementation. Думаю, что и методы тоже. Может не прав. Проверять лень.

← →
Alkid © (2006-05-15 18:31) [9]

> - если тебе так не нравится fastcall, используй cdecl...
> А для того чтобы "Дельфи" позаботился о твоем кривом коде,
> наподобие MSVC, достаточно влючить Compiler->Stack frames,
> Range checking и Owerflow checking... А адреса, построчно,
> можно посмотреть в map файле, если включить Linker->Map
> file->Detailed...
> А увлекаться "трассировкой стандартных библиотек Delphi
> в режиме дизассемблера" - надо со включенным Use Debug DCU,
> чтобы мозги на место вжать...

Зря Вы так презрительно. Я ведь не от жизни хорошей до этого дошёл, а от того, что описанное вами эффекта уже не дало:

В библиотеках я соглашение о вызове менять не могу,
Stack frames давно включено.
DEBUG DCUs в случае динамической линковки VCL эффекта не дают
(а статически линковать не мог, специфика проекта),
Range checking & Overflow checkings здесь роли не играют.
Map-file я тоже использовать не могу, ибо мне над маппить именно библиотеку, которая ещё фиг знает куда отобразится при загрузке.

← →
Desdechado © (2006-05-15 18:32) [10]

а у меня, например, сразу возникло подозрение, что порядок следования зависит еще и от того, от чего наследуется класс и переопределяются ли в нем методы

← →
begin...end © (2006-05-15 18:33) [11]

> Alkid © (15.05.06 18:08)

> Суть проблемы состоит в том, что бы отследить происхождение
> одного мистического обращения к уже уничтоженному объекту.

А каким образом эта проблема связана с вопросом о порядке размещения методов?

← →
Alkid © (2006-05-15 18:33) [12]

> а у меня, например, сразу возникло подозрение, что порядок
> следования зависит еще и от того, от чего наследуется класс
> и переопределяются ли в нем методы

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

> А каким образом эта проблема связана с вопросом о порядке
> размещения методов?

Дело в том, что непосредственно тот самый гадкий вызов осуществляет неидентифицированная функция, распологающаяся в памяти сразу перед конструктором TControl.Create(...). На первый взгляд кажется, что это он и есть, но анализ листинга дизассемблера говорит о том, что это не он, а другая функция (чётко виден эпилог конструктора, промежуточный nop и пролог этой функции). Вот и думаю, может быть, если я её идентифицирую и найду исходник, то смогу разобраться, где я накосячил.

← →
vrem (2006-05-15 19:04) [14]

>Вопрос по "кишочкам"
Фраза респект! :)

> Alkid © (15.05.06 18:36) [13]

А что тебе мешает дотрассировать до вызова этой функции? Не по исходникам, так в режиме CPU View? В Delphi же нет "черных ящиков", любой участок программы прозрачен и открыт.

Попробуй турбо-дебагером воспользоваться или идой.

> А что тебе мешает дотрассировать до вызова этой функции?
> Не по исходникам, так в режиме CPU View? В Delphi же нет
> "черных ящиков", любой участок программы прозрачен и открыт.

Я тут фишку нарыл - иногда в Дельфёвом дизассемблере теряется указание того, что в конкретном адресе начинается функция из-за того, что дизассемблер слегка "промахивается" и начало функции не совпадает с границей его шага при отображении памяти.

> Попробуй турбо-дебагером воспользоваться или идой.

Спасибо, уже разобрался. При помощи окна модулей вычислил, что это был деструктор TControl.Destroy.

Расположение кода в образе Найти похожие ветки