Формат MAP-файла, генерируемый компилятором или линкеро
Модератор: Модераторы
- *vmr
- постоялец
- Сообщения: 168
- Зарегистрирован: 08.01.2007 00:46:07
- Откуда: Киев
- Контактная информация:
http://www.koders.com/delphi/fid268D5BE ... ?s=network
Код: Выделить всё
unit uDebug;
// ------------------------------------------------------------------
// Unit name: uDebug
// Author: Eddy Vluggen
// Purpose: Unit to make debugging easier
// ------------------------------------------------------------------
interface
function LoadAndParseMapFile: Boolean;
procedure CleanUpMapFile;
function GetMapAddressFromAddress(const Address: Cardinal): Cardinal;
function GetMapFileName: string;
function GetModuleNameFromAddress(const Address: Cardinal): string;
function GetProcNameFromAddress(const Address: Cardinal): string;
function GetLineNumberFromAddress(const Address: Cardinal): string;
******
Насколько brutalstrip эффективнее чем strip идущий с fpc (в плане уменьшения размера исполняемого файла)?
Вопрос неверен.
Он просто умеет удалять то, чего strip удалять *не* умеет (т.е. информацию в формате dwarf2).
strip работает по принципу "чего не понимаю - того не трогаю".
brutalstrip - "всё, что не разрешено - запрещено". На то он и брутал. Но список секций там зашит в константу-массив, исходник прилагается, так что правится это всё одним движением левой пятки.
unit uDebug;
Спасибо за ссылку, попробую найти применение.
Сам юнит для меня бесполезен, поскольку не GNU GPL.
З.Ы. И дата - 2001 год - не звучит обнадёживапюще.
-
Padre_Mortius
- энтузиаст
- Сообщения: 1265
- Зарегистрирован: 29.05.2007 17:38:07
- Откуда: Спб
И вообще весь смысл за бруталстрипом - "а вот хорошо бы иметь свои тулзы для работы с экзешниками, с исходниками на Паскале, легко модифицируемые и перестраиваемые, и не зависеть от чужого дяди".
ФПЦ, в отличие от Дельфи, развивается стремительно. Оборотная сторона этого - всё столь же стремительно устаревает. Форматы меняются, сменяются другими... Только успевай поспевать да адаптироваться
Ну у нас с Delphi7 он работает на ура
ФПЦ, в отличие от Дельфи, развивается стремительно. Оборотная сторона этого - всё столь же стремительно устаревает. Форматы меняются, сменяются другими... Только успевай поспевать да адаптироваться
- Sergei I. Gorelkin
- энтузиаст
- Сообщения: 1409
- Зарегистрирован: 24.07.2005 14:40:41
- Откуда: Зеленоград
хм... у меня чегото brutalstrip не компилиться
fpc от релизного лазаруса 0.9.24
а разве так вообще можно?
объявлять как TFileStream
а использовать как TMemoryStream
Код: Выделить всё
c:\chelinfo>fpc brutalstrip
Free Pascal Compiler version 2.2.0 [2007/11/14] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Win32 for i386
Compiling brutalstrip.pp
Compiling un_lineinfo.pp
Compiling un_xtrctdwrflnfo.pp
un_xtrctdwrflnfo.pp(118,2) Warning: Illegal compiler directive "$IOERRORS"
un_xtrctdwrflnfo.pp(373,6) Note: Local variable "fo" not used
un_xtrctdwrflnfo.pp(374,3) Note: Local variable "IsExternal" not used
un_xtrctdwrflnfo.pp(647,30) Warning: Local variable "cofftable" does not seem to
be initialized
un_xtrctdwrflnfo.pp(560,8) Note: Local variable "j" not used
un_xtrctdwrflnfo.pp(562,5) Note: Local variable "p" not used
un_xtrctdwrflnfo.pp(563,5) Note: Local variable "ib" not used
un_xtrctdwrflnfo.pp(737,27) Warning: Mixing signed expressions and longwords giv
es a 64bit result
un_xtrctdwrflnfo.pp(679,8) Note: Local variable "j" not used
un_xtrctdwrflnfo.pp(679,11) Note: Local variable "n" not used
un_xtrctdwrflnfo.pp(679,23) Note: Local variable "rmv" not used
un_xtrctdwrflnfo.pp(680,5) Note: Local variable "dlil" is assigned but never use
d
un_xtrctdwrflnfo.pp(681,5) Note: Local variable "p" not used
un_xtrctdwrflnfo.pp(682,5) Note: Local variable "ib" not used
un_xtrctdwrflnfo.pp(682,17) Note: Local variable "maxrvl" not used
un_xtrctdwrflnfo.pp(115,3) Note: Local variable "ELFDlin" not used
un_xtrctdwrflnfo.pp(116,3) Note: Local variable "ZELFDlin" not used
un_xtrctdwrflnfo.pp(259,3) Note: Local variable "ExeFileName" not used
un_xtrctdwrflnfo.pp(260,3) Note: Local variable "header" not used
un_xtrctdwrflnfo.pp(261,3) Note: Local variable "strtab_header" not used
un_xtrctdwrflnfo.pp(262,3) Note: Local variable "cursec_header" not used
un_xtrctdwrflnfo.pp(264,3) Note: Local variable "buf" not used
un_lineinfo.pp(339,9) Note: Local variable "temp" is assigned but never used
un_lineinfo.pp(414,22) Warning: Mixing signed expressions and longwords gives a
64bit result
un_lineinfo.pp(418,34) Warning: Mixing signed expressions and longwords gives a
64bit result
un_lineinfo.pp(422,26) Warning: Mixing signed expressions and longwords gives a
64bit result
un_lineinfo.pp(468,38) Warning: Mixing signed expressions and longwords gives a
64bit result
un_lineinfo.pp(274,5) Note: Local variable "temp_length" not used
un_lineinfo.pp(281,5) Note: Local variable "c" not used
un_lineinfo.pp(283,5) Note: Local variable "b" not used
brutalstrip.pp(54,27) Error: Incompatible types: got "TMemoryStream" expected "T
FileStream"
brutalstrip.pp(68) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: C:\lazarus\fpc\2.2.0\bin\i386-win32\ppc386.exe returned an error exitcode
(normal if you did not specify a source file to be compiled)
fpc от релизного лазаруса 0.9.24
а разве так вообще можно?
объявлять как TFileStream
Код: Выделить всё
f,f2: TFileStream;а использовать как TMemoryStream
Код: Выделить всё
then f:= TMemoryStream.CreateСтранно. У меня всё компилировалось.
В принципе, такой бред должен давать ошибки только в рантайме - да и то если повезёт.
Наверно от конфига компилятора зависит.
В любом случае, поправил на TStream и перезакачал архив.
В принципе, такой бред должен давать ошибки только в рантайме - да и то если повезёт.
Наверно от конфига компилятора зависит.
В любом случае, поправил на TStream и перезакачал архив.
Я пишу на паскале dll'ку, которая затем используется в java-программе (не хочу связываться с gui на паскале). Иногда в этой dll'ке возникают исключения. Можно ли использовать ваши разработки в этой ситуации? Ведь java-машина ставит свои обработчики исключений...
На сколько я понимаю, мне придется окружить весь код функций в try-catch, но вот как вывести информацию по перехваченному исключению с помощью un_lineinfo я понять не могу
.
На сколько я понимаю, мне придется окружить весь код функций в try-catch, но вот как вывести информацию по перехваченному исключению с помощью un_lineinfo я понять не могу
- alexs
- долгожитель
- Сообщения: 4066
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
Отладь сначала dll в родной для неё среде.
используй побольше логирования - во всех подозрительных местах вставь запись промежуточных данных в лог.
Получится гораздо удобнее, чем сидеть с отладчиком и трасить весь код.
используй побольше логирования - во всех подозрительных местах вставь запись промежуточных данных в лог.
Получится гораздо удобнее, чем сидеть с отладчиком и трасить весь код.
Прога занимается перебором огромного числа вариантов. Если ошибка происходит не на первых шагах расчета - разобраться в отладочном выводе не возможно. Поэтому место исключения знать очень важно. Я уж не говорю о том, что поиск строки с помощью отладочного вывода занимает очень много времени.
