Прикольная зависимость от типа отладочной информации

Вопросы программирования на Free Pascal, использования компилятора и утилит.

Модератор: Модераторы

Прикольная зависимость от типа отладочной информации

Сообщение Cheb » 08.04.2017 20:56:02

Win64.
Если использовать говно мамонта dwarf2 (-gl -gw) то база образа будет 00100000000h
Если использовать штатную stabs (-gl) то база образа будет 00000400000h :lol:

ИЧСХ, адреса в отладочном формате stabs имеют тип dword :mrgreen:

Для непосвящённых: база образа (image base) - это место в виртуальном адресном адресном пространстве, куда операционная система должна по идее загрузить исполняемый код екзешника. Обычно совпадает с фактическим, но если дерьмо случается и диапазон адресов занят (вполне обычно для DLL'ок), то ОС выполняет релокацию (грузит в другое место и подправляет все адреса в коде).

Добавлено спустя 1 час 21 минуту 3 секунды:
З.Ы. А вот хрен. К DLL это не относится (база выше 4гиг), и всё штатно работает путём обрезания адреса до dword чтобы сличить со stabs.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 592
Зарегистрирован: 06.06.2005 15:54:34

Re: Прикольная зависимость от типа отладочной информации

Сообщение скалогрыз » 09.04.2017 07:12:56

как вообще stabs создался для 64-битных приложений?
в stabs техническое ограничение на 32 бита.

если он всё-таки умудрился создаться, то я настойчивно не рекомендую его использовать или полагаться на его значения.
скалогрыз
долгожитель
 
Сообщения: 1645
Зарегистрирован: 03.09.2008 02:36:48

Re: Прикольная зависимость от типа отладочной информации

Сообщение Cheb » 09.04.2017 14:44:44

в stabs техническое ограничение на 32 бита.

Тупо отрезаются 32 младших бита адреса, и используются.
Проверил, всё пучком (конвертировал lineinfo в свой движок, заметно изменив его). Отлично работает на DLL'ах, грузящихся выше 4Гб с реаллокацией.
Код: Выделить всё
        {$push}
          {$rangechecks off}
          {$overflowchecks off}
          addr:= dword(ptruint(ptruint(address) - ptruint(base_addr) + ptruint(ExeImageBase)));
        {$pop}


THE MODULE Test #21 (texture atlas) HAS CRASHED

Module logic thread #0:
Error sending input events to GUI elements

Class TButton crashed at calling the event subscriber TModuleMainMenu.CommitSuicideByAV()

The exception was sucessfully caught in the module DLL.

Call stack:
mo_gui.pp:2716 (tmodulemainmenu.commitsuicidebyav) in _test021-x86_64.dll
mo_gui.pp:737 (tcontrol.passevent) in _test021-x8664.dll
mo_gui.pp:1817 (tbutton.onkey) in _test021-x86_64.dll
mo_gui.pp:1363 (ttable.onkey) in _test021-x86_64.dll
mo_gui.pp:1363 (ttable.onkey) in _test021-x86_64.dll
m_gui.pp:2670 (tmodulemainmenu.onkey) in _test021-x86_64.dll
mo_logic_input.inc:174 (tlogic.onpress) in _test021-x86_64.dll
mo_logic_input.inc:34 (tlogic.processmessages) in_test021-x86_64.dll
mo_logic.pp:898 (tlogic.pulse) in _test021-x86_64.dll
mo_threads.pp:833 (tlogicthread.execute) in _test021-x86_64.dll
:3148 in _test021-x86_64.dll
:348 in _test021-x86_64.dll

Mother has passed an unhandled exception to the module in thread Module logic thread #0

VEH caught C0000005h, Access Violation,

Attempt to write t the NULL address
mo_gui.pp:2713 (tmodulemainmenu.commitsuicidebyav) in _test021-x86_64.dll


Добавлено спустя 4 часа 6 минут 49 секунд:
P.S.
3.0.0 на убунту x86_64 таки генерирует dwarf2 по -gl
Что прискорбно, ибо dwarf2 кривой.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 592
Зарегистрирован: 06.06.2005 15:54:34

Re: Прикольная зависимость от типа отладочной информации

Сообщение скалогрыз » 09.04.2017 19:34:15

Cheb писал(а):Тупо отрезаются 32 младших бита адреса, и используются.
Проверил, всё пучком (конвертировал lineinfo в свой движок, заметно изменив его). Отлично работает на DLL'ах, грузящихся выше 4Гб с реаллокацией.

да нет же ш! ну что тебя жизнь не чему не учит что ли?
от скольки таких вот хакерских решений ты огрёб?! и сколько таких вот хакерских решений ты разгрёб?!

ты же не пишешь решение под какие-то узкие рамки. нет. ты пишешь двиг, который ориентируется на многие поколения железа и fpc компилятора.
так что не нужно полагаться на то, что нечто работающие исключительно под 32 будет работать под 64.
Неделю назад же было
скалогрыз
долгожитель
 
Сообщения: 1645
Зарегистрирован: 03.09.2008 02:36:48

Re: Прикольная зависимость от типа отладочной информации

Сообщение Cheb » 09.04.2017 21:30:08

ну что тебя жизнь не чему не учит что ли?

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

Добавлено спустя 2 минуты 13 секунд:
З.Ы. И у меня в движке адаптивная система, тулзы которые создают внешний файл с отладочной информацией умеют питаться тем, что есть - то есть, поддерживаются и dwarf2 и stabs. Но dwarf2, как я уже говорил, генерируется через анус и не умеет имена функций.

Добавлено спустя 4 минуты 50 секунд:
З.З.Ы. Как мои велосипеды, так и новый lineinfo паскаля (некоторые фрпгменты которого подозрительно похожи на куски моих велосипедов, лол) сначала определяют к какому исполняемому модулю принадлежит адрес, а потом уже лезут выковыривать информацию о строках из этого модуля.

Единственно, у меня гибче, и, если, допустим, в EXE stabs, а в DLL dwarf2, то всё равно нормально отработает (допустим, бектрейс переходит между двумя этими исполняемыми модулями).
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 592
Зарегистрирован: 06.06.2005 15:54:34

Re: Прикольная зависимость от типа отладочной информации

Сообщение Mirage » 09.04.2017 23:27:52

Cheb писал(а):Но dwarf2, как я уже говорил, генерируется через анус и не умеет имена функций.


Что значит не умеет имена функций? Gdb показывает имя функции, на которой остановился (как для dwarf, так и для stabs), значит в отладочной информации они есть.
И даже функцию вызвать из отладчика можно. А вот метод - только если dwarf3.

Cheb писал(а):Единственно, у меня гибче


Может имее смысл патчик отправить разработчикам?
Mirage
энтузиаст
 
Сообщения: 752
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Прикольная зависимость от типа отладочной информации

Сообщение Cheb » 10.04.2017 00:23:20

Что значит не умеет имена функций? Gdb показывает имя функции, на которой остановился

? :(
Парсер, который я цельнотягнул, не умел.
И не помню, чтобы при парсинге вылезали какие либо строки, похожие на имена функций.
И блок dwarf2 слишком слишком маленький (обычно около 50 килобайт в пожатом виде - в 10 раз меньше, чем stabs)
Возможно, это *ещё* какой-то блок в екзешнике, о котором я не знаю, помимо '/30' (вынь) / '.debug_line' (линь)

имее смысл патчик отправить разработчикам?

Не имеет: я многое приношу в жертву удобству, в отличие от очень строгой RTL. Один алгоритм, например, переработал чуть менее, чем полностью, т.к. в lineinfo было построено на статических массивах, коротких строках и прямом чтении из файла, чтобы обойтись без аллокаций.
Это всё равно, что умение подтереться трамвайным билетиком: кому-то когда-то жизненно нужное, но мне не спёрлось. У меня игра, расход памяти сотни мегабайт априори.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 592
Зарегистрирован: 06.06.2005 15:54:34


Вернуться в Free Pascal Compiler

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3

Рейтинг@Mail.ru