Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Image Base

10
31 марта 2005 года
Freeman
3.2K / / 06.03.2004
Даже не знаю, в какой форум было правильнее всего запостить данную тему. Думаю, что не ошибся.

Короче, вопрос такой: заморачивался ли кто-либо правильной установкой параметра Image base при сборке проекта?

Интересует научный подход к делу с одной стороны и воплощение его на практике - с другой. Например, что пишет Рихтер по этому поводу, кто читал? Мне не повезло - в хорошее время не озадачился, а сейчас постоянная запарка - читать что-то уже сил нет.

Непосредственная задача: программа или группа программ, разрабатываемые на Borland Delphi. По соображениям экономии трафика на обновлениях, рассылаемых клиентам, было принято решение собрать собственные библиотеки времени выполнения (aka BPL'ы). Между программистами возник спор, насколько это эффективно с точки зрения разделения кода во время выполнения, и насколько правильно выставленный Image Base помогает (или мешает) страничной адресации в NT.

Я - сторонник использования библиотек, мой оппонент - противник. Сейчас сошлись на временности решения в целях экономии трафика. Хотелось бы поставить аргументированную точку в решении вопроса.
487
31 марта 2005 года
ddnh_bc
301 / / 16.09.2003
Цитата:
Originally posted by smartsoft
Даже не знаю, в какой форум было правильнее всего запостить данную тему. Думаю, что не ошибся.

Короче, вопрос такой: заморачивался ли кто-либо правильной установкой параметра Image base при сборке проекта?

Интересует научный подход к делу с одной стороны и воплощение его на практике - с другой. Например, что пишет Рихтер по этому поводу, кто читал? Мне не повезло - в хорошее время не озадачился, а сейчас постоянная запарка - читать что-то уже сил нет.

Непосредственная задача: программа или группа программ, разрабатываемые на Borland Delphi. По соображениям экономии трафика на обновлениях, рассылаемых клиентам, было принято решение собрать собственные библиотеки времени выполнения (aka BPL'ы). Между программистами возник спор, насколько это эффективно с точки зрения разделения кода во время выполнения, и насколько правильно выставленный Image Base помогает (или мешает) страничной адресации в NT.

Я - сторонник использования библиотек, мой оппонент - противник. Сейчас сошлись на временности решения в целях экономии трафика. Хотелось бы поставить аргументированную точку в решении вопроса.



Честно говоря, мое мнение - с Image Base заморачиваться особого смысла нет. Фактически, это дефолтовый параметр глабальной адресации памяти внутри файла. Если система не сможет загрузить файл в адрес характеризуемый Image Base - то загрузит в другой. Единственная потеря времени при этом - это пересчет адресов по Relocation Table. Но, честно говоря, потери эти настолько смехотворны...

10
01 апреля 2005 года
Freeman
3.2K / / 06.03.2004
Цитата:
Originally posted by ddnh_bc
Но, честно говоря, потери эти настолько смехотворны...


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

487
01 апреля 2005 года
ddnh_bc
301 / / 16.09.2003
Цитата:
Originally posted by smartsoft
Че, серьезно, что ли? А можно привести какую-нить ссылку, чтобы можно было ткнуть в качестве доказательства. Мы тут доспорились до черт знает чего, а аргументированно выступить я не могу.



Честно говоря, ссылку такую припомнить не могу - но могу привести выдержку из описания формата PE касающуюся как раз именно этого вопроса:

Цитата:

[COLOR=blue]
Таблица настроек адресов содержит элементы для всех фиксированных адресов в образе программы. Поле в заголовке PE файла с названием FixUp's Data Size содержит общий размер в байтах данной таблицы. Сама таблица настроет адресов разбита на блоки настроек (каждый блок представляет настройки для 4-х килобайтовой страницы).
Связанные линкером адреса не нуждаются в дополнительной настройке загрузчиком до тех пор, пока загрузчик в состоянии загрузить программу по адресу, указанному в ее заголовке. При невыполнении этого условия загрузчику прийдется корректировать адреса в программе. С учетом FLAT модели памяти и виртуализации адресного пространства для каждого процесса загрузчику никогда не прийдется изменять эти адреса, исключением могут являться библиотеки, которые многое компиляторы привязывают к одному фиксированному адресу (Borland например), либо случайные конфликты в адресах библиотек.

Блок настроек перемещений (FixUp Block)
--------------------------------------------------------------------------------

Блок настроек имеет следующий довольно простой формат:

FixUp Block
Base Size or Type Name Of field Brief description
00h DWord Page RVA Указатель на страницу применения настроек перемещений
04h DWord Block Size Размер блока настроек (с заголовком)
08h Word TypeOffset Record Массив записей настроек, их переменное количество
Total Structure size ... таблица имеет переменный размер

Для наложения настройки необходимо вычислить Дельта-значение. 32-битное Дельта есть разница между желаемой базой загрузки и действительной. Если образ программы загружен в требуемое место, то Дельта равна нулю и никакой настройки произойти не может. Каждый блок настроек должен начинаться на DWord границе (не проверял), для выравнивания блока можно пользоваться нулями.
При настройке необходимую позицию в блоке вычисляют как сумму Page RVA и Image Base загруженной программы. TypeOffset определен следующим образом:

TypeOffset Entry
15 . . . 12
--------------------------------------------------------------------------------
Type 11 . . . 0
--------------------------------------------------------------------------------
Offset Биты слова, Type указывает на тип настройки, а Offset на ее смещение внутри 4-килобайтового блока применимости настроек.


Поле Type имеет следующие значения:
0h - адрес абсолютный и никаких изменений производить не требуется.
1h - добавить старшие 16 битов Дельты к 16 битовому полю находящемуся по смещению Offset. 16 битовое поле представляет старшие биты 32-битового слова.
2h - добавить младшие 16 битов Дельты по смещению Offset. 16-битовое поле представляет младшую половину 32-битового слова. Данная запись настройки присутствует только на RISC машине когда Object align не является по умолчанию 64К.
3h - прибавляет 32-битовое Дельта к 32-битовому значению.
4h - настройка требует полного 32-битового значения. Старшие 16-бит берутся по адресу Offset, а младшие в следующем элементе TypeOffset Все это объединяется в знаковую переменную, затем добавляется 32-битовое дельта и DWord 8000h. Старшие 16 бит получившегося значения сохраняются по адресу Offset в 16-битовом поле.
5h - ? что-то связанное с MIPS.

В реальной жизни я сталкивался только с типами 0 и 3, все остальные на интелах очевидно не столь юзабельны, интересное поле для экспериментов. Все прочие типы перемещений зарезервированы Microsoft.
[/COLOR]



А рассчитать затраты по этим параметрам - сам понимаешь дело 5 минут.

Если хочешь - могу добавить еще сам хелп по PE формату (хотя где-то я его уже постил).

10
02 апреля 2005 года
Freeman
3.2K / / 06.03.2004
Цитата:
Originally posted by ddnh_bc
А рассчитать затраты по этим параметрам - сам понимаешь дело 5 минут.


Спасибо, понятно.

Кстати, не подскажешь, с помощью какой проги можно исследовать карту памяти процесса с обсуждаемой точки зрения? Это будет полезно не только с целью настройки image base.

487
02 апреля 2005 года
ddnh_bc
301 / / 16.09.2003
Цитата:
Originally posted by smartsoft
Спасибо, понятно.

Кстати, не подскажешь, с помощью какой проги можно исследовать карту памяти процесса с обсуждаемой точки зрения? Это будет полезно не только с целью настройки image base.



Если ты имеешь ввиду прогу которая бы показала количество и структуру релоков - то такой нет. Но в ознакомительных целях могу дать посмотреть исходники класса для работы с PE файлами. Я его в свое время писал для других целей - и сейчас полностью переработал - но новую версию сейчас дать не могу. А старая в ознакомительных целях вполне сгодится - там как раз есть функция пересчета к новому Image Base-у. Все используемые структуры в MSDN есть.

Краткий хелп:

 
Код:
load(char *name);

Загрузка файла. true - если файл успешно загрузился, false - если нет.
 
Код:
setbase(DWORD base);

Собственно пересчет к новому Image Base. Параметр base - виртуальный адрес нового Image Base.
 
Код:
executable(int index);

Возвращает true если секция с индексом index содержит исполняемый код.
 
Код:
codelimit(int index);

Это неинтересно. Влепил в свое время для собственного дизассемблера. Как оказалось - пятое колесо в телеге. Можно даже не смотреть.


P.S. Как там кстати МИЭТ поживает?
10
02 апреля 2005 года
Freeman
3.2K / / 06.03.2004
Цитата:
Originally posted by ddnh_bc

P.S. Как там кстати МИЭТ поживает?


Цветет и пахнет.

10
03 апреля 2005 года
Freeman
3.2K / / 06.03.2004
Цитата:
Originally posted by ddnh_bc
А старая в ознакомительных целях вполне сгодится - там как раз есть функция пересчета к новому Image Base-у.


Вот что надумал. Если прога, вроде Process Explorer, показывает, что библиотека загружена по тому адресу, что указан в Image Base, значит он "работает". Если нет - можно попробовать поискать другой адрес.

Разумеется нельзя дать гарантий на все системы, особенно на будущие или нестандартные версии, но для большинства случаев такой метод вроде сойдет.

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог