Difference between revisions of "FpDebug/ru"

From Lazarus wiki
Jump to navigationJump to search
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{LanguageBar}}[[Category:Debugging]]
+
{{FpDebug}}
  
 
= О пакете =
 
= О пакете =
Line 32: Line 32:
 
* http://sourceforge.net/projects/duby/
 
* http://sourceforge.net/projects/duby/
  
== Устанровка в IDE ==
+
== Установка в IDE ==
 
Установите пакет LazDebuggerFp
 
Установите пакет LazDebuggerFp
  
= General Debugging Issues =
+
= Общие проблемы отладки =
  
These issues can not be fixed by the debugger alone. They need changes in FPC too. Some may also be affected by lack of support in DWARF.
+
Эти проблемы не могут быть исправлены одним отладчиком. Им тоже нужны изменения в FPC. На некоторых может также повлиять отсутствие поддержки в DWARF.  
  
These issues apply to all debugger backends.
+
Эти проблемы относятся ко всем серверным модулям отладчика.
  
== Properties ==
+
== Свойства ==
  
Properties are one of the most wanted features for (any of) the debugger(s).
+
Свойства - одна из наиболее востребованных функций (любого) отладчика(ов).  
Here is why they can not yet be inspected, and why it will still be a good while before this happens.
+
Вот почему они еще не могут быть проверены, и почему до этого пройдет еще немало времени.
  
Before going into details: For "<u>Properties without getter function</u>" (i.e., "<u>with direct field access</u>") FPC (as means to a workaround of the issue) currently adds an entry for a variable with the property name.
+
Прежде, чем вдаваться в подробности: для «<u>Свойства без getter-функции»</u> (т.е. «<u>с прямым доступом к полю</u>») FPC (как средство решения проблемы) в настоящее время добавляет запись для переменной с именем свойства.  
This means such properties can be displayed. They can also be written by the debugger (if the debugger supports changing data), and if they are written this is done bypassing any Setter procedure, since the debugger has no clue there even is a setter.
+
Это означает, что такие свойства могут отображаться. Они также могут быть записаны отладчиком (если отладчик поддерживает изменение данных), и если они записаны, это делается в обход любой процедуры Setter, поскольку отладчик не знает, есть ли даже сеттер.
  
There are several missing pieces for allowing the debugger to show (and maybe modify) properties.
+
Есть несколько недостающих частей, позволяющих отладчику показывать (и, возможно, изменять) свойства.  
  
* The debugger needs support to call functions
+
* Отладчику нужна поддержка для вызова функций.
* FPC needs a way to actually add info about the "properties" to the debug info.
+
* FPC нужен способ добавить информацию о «свойствах» к отладочной информации.
  
As for calling function. This may just be missing implementation in the debugger. This has not yet been investigated in any more depth. It may or may not require additional info in the DWARF generated by FPC
+
Что касается вызова функции. Это просто может отсутствовать реализация в отладчике. Это еще не было исследовано более глубоко. Может потребоваться или не потребоваться дополнительная информация в DWARF, созданном FPC.
  
As for adding "properties" to the debug info:
+
Что касается добавления «свойств» к отладочной информации:  
DWARF (at least version 2 and 3 / not checked 4 or 5) does not actually have any way to encode this info.
+
DWARF (по крайней мере версии 2 и 3 / не проверено 4 или 5) фактически не имеет возможности кодировать эту информацию.  
Consequently FPC currently does not add it either.  
+
Следовательно, FPC в настоящее время также не добавляет его.
  
In case that DWARF does not add this in time, DWARF allows for vendor specific data (afaik). Up until now, no debugger would have known about any "private fpc data", so there was no point. In future such data could be agreed between FPC and FpDebug. But that is still a good way off. FpDebug does not even do function calling yet.
+
В случае, если DWARF не добавит это вовремя, DWARF позволит использовать данные от производителя (afaik). До сих пор ни один отладчик не знал бы о каких-либо «частных данных fpc», поэтому в этом не было никакого смысла. В будущем такие данные могут быть согласованы между FPC и FpDebug. Но до этого еще далеко. FpDebug еще даже не выполняет вызов функций.
  
 +
== Strings (vs PChar и Array of Char) ==
  
== Strings (vs PChar and Array of Char) ==
+
Первоначально в DWARF не было концепции кодирования строк. Это было добавлено в DWARF 4 (требуется проверка), но еще не исследовано на предмет удобства использования с FPC. Также в FPC в настоящее время реализованы только DWARF 2 и 3 (с первыми шагами к версии 4).
  
Originally DWARF had no concept to encode strings. This has been added in DWARF 4 (need verification), but not yet been investigated for usability with FPC. Also FPC currently only implements DWARF 2 and 3 (with first steps towards version 4).
+
Остается только 2 способа кодирования строки в DWARF.  
 +
* Как указатель на char
 +
* Как массив char
  
This leaves only 2 ways to encode a string in DWARF.
+
Какой из них используется, зависит от версии FPC и от того, используется ли DWARF 2 или 3.  
  
* As pointer to char
+
Если это «указатель на char», то это делает его неотличимым от реального PChar.
* As array of char
+
По этой причине все отладчики в Lazarus иногда для таких отслеживаемых выражений, как <code>SomeString[4]</code>, показывают результат «PChar: 'a'; String: 'b'». Поскольку PChar начинается с нуля, а строка - с единицы, индекс «4» может означать 4-й или 5-й символ.
  
Which one is used depends on the version of FPC, and if DWARF 2 or 3 is used.
+
Недавние FPC используют «массив символов», когда они генерируются DWARF 3.
 +
В том, что у них (в настоящее время) есть различия в деталях реализации между тем, как они кодируют строки и реальный массив символов. (Например, пропуск необязательного/избыточного бита информации. В данном случае: DW_AT_byte_stride).
 +
Эти детали не имеют смысла с точки зрения любого другого отладчика, но FpDebug может их обнаружить, поскольку знает об этих деталях реализации. Конечно, это очень ненадежно, следующая версия FPC всегда может это изменить.
  
If it is "pointer to char", then this makes in indistinguishable from actual PChar.
+
Аналогичным образом FPC обрабатывает ShortStrings внутри как запись и кодирует их как есть. Опять же, различие заключается в деталях реализации.
This is the reason all debuggers in Lazarus sometimes for a watch like "SomeString[4]" show the result "PChar: 'a'; String: 'b'". Because PChar is zero-based and string one-based, the index "4" can mean the 4th or the 5th char.
 
  
Recent FPC use the "array of char" when they generate DWARF 3.
+
== Изменение управляемых типов ==
In that they have (currently) implementation detail differences between how they encode strings and real array of char. (Such as the omission of an optional/redundant bit of information. In this case: DW_AT_byte_stride).
 
Those details are meaningless from the point of any other debugger, but FpDebug can detect them as it knows about those implementation details. Of course this is extremely fragile, the next version of FPC can always change this.
 
  
In a similar way FPC handles ShortStrings internally as record, and encodes them as this. Again distinguishing this is down to implementation details.
+
Это применимо к любому отладчику, который может устанавливать новые значения для списка слежения (изменяет переменную в отлаживаемом exe).  
  
== Modifying managed types ==
+
Управляемые типы не могут быть изменены корректно.
  
This applies to any debugger that can set new values to a watch (modify variable in the debugged exe).
+
Для изменения управляемых типов отладчику необходимо знать:
 +
* счетчик ссылок
 +
* копирование при записи
 +
* как выделить/освободить память / или лучше как вызвать методы inc/dec_ref для каждого типа, чтобы они выполняли работу правильно
  
Managed types can not be correctly modified.
+
Ничего из этого не доступно.
  
To modify managed types the debugger would need to know about:
+
Если вы присваиваете новое значение строке или динамическому массиву, то необходимо скорректировать счетчик ссылок старого и нового значения. При необходимости память должна быть выделена или освобождена.
* the ref count
+
Если это сделать неправильно, это, по крайней мере, вызовет утечку памяти. Но это также может вызвать сбои или другие случайные ошибки, когда отлаженный exe продолжает работу.
* copy on write behaviour
 
* how to allocate/free memory / or better how to call the inc/dec_ref methods for each types, so they will do the work correctly
 
  
None of that info is available.
+
В массиве можно изменить один элемент. "SomeArray[5] := 7;". Если на массив ссылаются несколько переменных, это повлияет на их всех. То же самое произойдет, если вы выполните этот оператор в своем приложении.
  
If you assign a new value to a string or dynamic array, then the ref count of the old and new value must be adjusted. If needed memory must be allocated or freed.
+
У строки (AnsiString) использует механизм копирование при записи (copy-on-write). Если вы сделаете "SomeString[4] := 'a'", тогда переменная, из которой вы получили доступ к строке, получит новую копию, и другие переменные (которые совместно используют память) не должны быть затронуты. У отладчика этой информации нет. Также у него нет доступа к счетчику ссылок и распределению/освобождению памяти (или внутренним строковым процессам).
If that is not done correctly it will at least cause a memory leak. But it can also cause crashes or random other buggy behaviour when the debugged exe continues.
 
  
In an array it is possible to change a single element. "SomeArray[5] := 7;". If the array is referenced from several variables, this will affect all of them. The same happens if you execute this statement in your app.
+
== Вызов функции с управляемыми типами в качестве параметра или результата ==
  
String (AnsiString) have copy-on-write. If you do "SomeString[4] := 'a'" then the variable from which you accessed the string gets a new copy, and other variables (that share the memory) should not be affected. The debugger does not have that info. Nor does it have access to the refcount and memory alloc/de-alloc (or internal string procs).  
+
Предполагая, что вызов функции был реализован в целом ....
  
== Calling function with managed types as param or result ==
+
По той же причине, что и в «Модификации управляемых типов», отладчик не может создавать строки или массивы для вызова функций, которые ожидают их как параметр.
  
Assuming function calling was implemented in general....
+
Значения результатов можно принять, но это вызовет утечку памяти.
  
For the same reason as in "Modifying managed types" the debugger could not create strings or arrays in order to call functions that expect them as param.
+
== Область действия / порядок поиска переменных ==
  
Result values could be accepted, but would cause a memory leak.
+
Существуют различные проблемы, при которых FPC не помещает достаточно информации в информацию DWARF, чтобы отладчик мог вычислить правильную область для всех переменных. В тех же случаях это может быть связано с тем, что DWARF не предлагает этого или не предлагает его в то время, когда он был реализован или последний раз обновлялся в FPC. Некоторые из них можно исправить, если FPC изменит способ кодирования информации.
  
== Scope / Variable search order ==
+
=== Вложенные процедуры ===
 
 
There are various issues where FPC does not put enough information into the DWARF info so that a debugger could compute the correct scope for all variables.
 
In same cases this may be due to DWARF not offering this, or not offering it at the time where it was implemented or last updated in FPC. Some of it may be fixable, if FPC would change the way it encodes the info.
 
 
 
=== Nested Procedures ===
 
  
 
<syntaxhighlight lang="pascal">
 
<syntaxhighlight lang="pascal">
var SomeVar: Integer; // global var
+
var SomeVar: Integer; // глобальная переменная
  
 
procedure Outer(NumText: string);
 
procedure Outer(NumText: string);
 
var  
 
var  
   SomeVar: Integer; // local var, declared above "Nested"
+
   SomeVar: Integer; // локальная переменная, объявленная выше "Nested"
  
 
   procedure Nested;
 
   procedure Nested;
Line 133: Line 130:
  
 
//var  
 
//var  
//  SomeVar: Integer; // local var, declared below "Nested"
+
//  SomeVar: Integer; // локальная переменная, объявленная ниже "Nested"
 
begin
 
begin
 
   Nested;
 
   Nested;
 
end;</syntaxhighlight>
 
end;</syntaxhighlight>
  
The local var "SomeVar" hides the global var of the same name, if you are in the procedure "Outer".  
+
Локальная переменная <code>SomeVar</code> скрывает глобальную переменную с таким же именем, если вы находитесь в процедуре «Outer».
The local var is also visible (and hides the global) if you are in "Nested".
+
Локальная переменная также видна (и скрывает глобальную), если вы находитесь в процедуре «Nested».
  
But if you comment the local var "declared above Nested" and uncomment the local var "declared below Nested", then the local var is no longer in the scope of "Nested".  
+
Но если вы закомментируете локальную переменную, "объявленную выше Nested", и раскомментируете локальную переменную, "объявленную ниже Nested", то локальная переменная больше не будет в области видимости "Nested".
"Nested" would now see the global var. ("Outer" still sees the local).
+
«Nested» теперь будет видеть глобальную переменную. («Outer» по-прежнему видит локальные переменные).
  
The DWARF info currently only tells the debugger that "SomeVar" is declared as local var in "Outer". And that "Nested" is inside "Outer".
+
Информация DWARF в настоящее время только сообщает отладчику, что <code>SomeVar</code> объявлена как локальная переменная в параметре "Outer". И это «Nested» находится внутри «Outer».
But the DWARF info does not include if "SomeVar" is declared above or below "Nested". So the debugger can not tell the difference. The debugger will in both cases show the local "SomeVar" when paused in "Nested"
+
Но информация DWARF не включается, если <code>SomeVar</code> объявлен выше или ниже "Nested". Так что отладчик не заметит разницы. В обоих случаях отладчик будет отображать локальную переменную <code>SomeVar</code>, если она приостановлена ​​в "Nested".
  
  
=== Global vars from other units ===
+
=== Глобальные перменные из других модулей ===
  
The DWARF info contains a section for each unit. All Symbols of a unit are listed in the correct section.
+
Информация DWARF содержит раздел для каждого модуля. Все символы модуля перечислены в правильном разделе.
However there is no info, which unit is in the "uses" clause of which other unit. And evidently even less, in which order they are used.
+
Однако нет информации о том, какой модуль входит в секцию "uses" какого другого модуля. И, очевидно, даже меньше, в каком порядке они используются.
  
If there are several global variables of the same name, one in each of several units, then FPC uses the order of the uses clause (right to left) to find the variable that will be seen from code in the current unit.
+
Если существует несколько глобальных переменных с одинаковым именем, по одной в каждом из нескольких модулей, то FPC использует порядок разделов uses (справа налево), чтобы найти переменную, которая будет видна из кода в текущем модуле.
  
If there is code in a unit FooBar that access a variable named NotInFooBar (that is not declared in unit FooBar), then this variable must be from one of the other units.
+
Если в модуле <code>FooBar</code> есть код, который обращается к переменной с именем <code>NotInFooBar</code> (которая не объявлена ​​в модуле <code>FooBar</code>), то эта переменная должна быть из одного из других модулей.
If there are several variables named NotInFooBar in different units, then the debugger has no information which one FPC did use.  
+
Если есть несколько переменных с именем <code>NotInFooBar</code> в разных модулях, то отладчик не имеет информации, какой из них именно использовал FPC.
The debugger is currently showing the first it finds. (Which is kind of random)
+
В настоящее время отладчик показывает первое найденное. (Что вроде случайно)
  
= FPC Issues =
+
= Проблемы FPC =
  
This affects all debuggers
+
Это влияет на все отладчики
  
* resourcestring  
+
* resourcestring
Currently not implemented https://bugs.freepascal.org/view.php?id=35571
+
В настоящее время не реализовано https://bugs.freepascal.org/view.php?id=35571
  
 
* const Foo = unicodestring('abc')
 
* const Foo = unicodestring('abc')
No debug info implemented https://bugs.freepascal.org/view.php?id=35569
+
Информация об отладке не реализована https://bugs.freepascal.org/view.php?id=35569
  
* type Foo = object (Dwarf 3) - Fixed in 3.3.3
+
* type Foo = object (Dwarf 3) - Исправлено в 3.3.3
Incorrectly encoded as class-instance https://bugs.freepascal.org/view.php?id=36017
+
Неправильно закодирован как экземпляр класса https://bugs.freepascal.org/view.php?id=36017
<br>The debugger can not display the data.
+
<br> Отладчик не может отобразить данные.
  
* Dynamic array when cross compiling
+
* Динамический массив при кросс-компиляции
 
https://bugs.freepascal.org/view.php?id=35567
 
https://bugs.freepascal.org/view.php?id=35567
<br>The debugger may calculate the length wrong.
+
<br> Отладчик может неправильно вычислить длину.
  
* Wrong stride for bitpacked array - Fixed in 3.3.3
+
* Неправильный шаг для битового массива - исправлено в 3.3.3
 
https://bugs.freepascal.org/view.php?id=36144
 
https://bugs.freepascal.org/view.php?id=36144
<br>FpDebug currently has a workaround
+
<br> В настоящее время у FpDebug есть обходной путь
  
= Status =
+
= Положение дел =
  
FpDebug supports Linux, Windows and MacOs.
+
FpDebug поддерживает Linux, Windows и MacO.
  
Any functionality regarding execution control (stepping/pausing...) is only tested for Linux and Windows. Support for this on Mac is incomplete/fragile.
+
Любые функции, касающиеся управления выполнением (пошаговое выполнение/приостановка ...), тестируются только для Linux и Windows. Поддержка этого на Mac неполная/ненадежная.
  
{{Note|For Windows/Linux please see '''[[Debugger Status]]'''}}
+
{{Note|Для Windows/Linux см. '''[[Debugger Status]]'''}}
  
For Mac support is currently considered "Alpha"
+
Поддержка Mac в настоящее время считается «альфа-версией»
Data evaluation can be used on Mac via the "LLDB+FpDebug" backend
+
Оценка данных может использоваться на Mac через серверную часть LLDB + FpDebug
  
The information is indicative and subject to updates / subject to further testing
+
Информация носит ориентировочный характер и может обновляться / подлежит дальнейшему тестированию.
  
== Notes ==
+
== Примечания ==
  
=== Stepping out ===
+
=== Пошаговый вывод ===
"Stepping out" relies on finding the caller address. The location of which depends on whether a function has a "stackframe" (use the BasePointer register) and has the frame already/still set-up.
+
«Пошаговый вывод» основан на поиске адреса вызова. Расположение которого зависит от того, есть ли у функции «стековый фрейм» (использует регистр BasePointer и ([[user:Zoltanleo|прим. перев.]]: представляет из себя структуры в стеке процессора)) и имеет ли уже/все еще настроенный фрейм.
Detection of this is limited to a few standard situations. (Especially in none FPC code, or optimized code this will not be detectable).
+
Обнаружение этого ограничено несколькими стандартными ситуациями. (Особенно это невозможно обнаружить в коде FPC или в оптимизированном коде).
  
Within un-optimized FPC code this feature works.  
+
Эта функция работает в неоптимизированном коде FPC.
  
=== Hardware Watchpoints (aka Data Breakpoints) ===
+
=== Аппаратные точки наблюдения (также известные как точки останова по данным) ===
Partly implemented for most data types (subset of the types supported by the hardware), including Conditions and other properties.
+
Частично реализовано для большинства типов данных (подмножество типов, поддерживаемых оборудованием), включая условия и другие свойства.
  
All watchpoints will have global scope. Watching a local var will alert you the next time the variable's memory is overwritten (e.g. if another variable takes the memory).
+
Все точки наблюдения будут иметь глобальную область действия. Наблюдение за локальной переменной будет предупреждать вас в следующий раз, когда память переменной будет перезаписана (например, если другая переменная займет память).
  
"Write only" watchpoints act as "read/write"
+
Точки наблюдения "только запись" действуют как "чтение/запись"
  
Watchpoints also trigger if they are overwritten with the value they already have.
+
Точки наблюдения также срабатывают, если они перезаписываются имеющимся у них значением.
  
Watchpoints do not show the before/after dialog.
+
Точки наблюдения не показывают диалоговое окно до/после.
  
Watchpoints that are not aligned to an address that is a multiply of their size, may be triggered by neighbouring values.
+
Точки наблюдения, которые не выровнены по адресу, кратному их размеру, могут запускаться соседними значениями.
E.g., a Word starting at an odd address, can be triggered by the byte before or after it. A 64 bit pointer must be aligned to an 8 byte boundary, or can be triggered by neighbours.
+
Например, Word, начинающееся с нечетного адреса, может запускаться байтом до или после него. 64-битный указатель должен быть выровнен по 8-байтовой границе или может запускаться соседями.
  
=== Thread and Stack ===
 
  
See "Stepping out". Relies on the same frame detection.
+
=== Поток и стэк ===
  
=== Watches / Locals / Inspect ===
+
См. «Пошаговый вывод». Полагается на то же обнаружение кадров.
Implemented
 
  
* Any missing types need to be discovered (i.e. not aware of any type that does not display, if not listed under "fpc issues"
+
=== Окно наблюдений / Локальные переменные / Осмотр ===
* currency types may not display the decimal dot (they will show value * 1000)
+
Реализовано
* Not all setting from the watch properties are implemented (most are not)
 
* Expressions:
 
** The debugger accepts expressions that it will calculate. Not all Pascal operators have been implemented.
 
** Expressions are calculated without range checks
 
*** simple terms (just an identifier)
 
**** Includes the value identifier "self" (if in a method), and the constants nil, true, false
 
*** typecasts
 
*** @ and ^ (address of and deref)
 
*** "^TFoo(x)" typecast x, as pointer to TFoo
 
*** () bracketed expression "a*(b+c)"
 
*** [] index for arrays, pointers, and pchar
 
*** . Foo.Bar access of members
 
*** constant numbers in decimal, hex ($), oct (&), bin (%)
 
*** constant string (ansistring)
 
*** +-*/ for int and float
 
*** mod for int
 
*** + for string
 
*** +- for pointer+int
 
*** div for int
 
*** = <> < > <= >= for int, float, string
 
*** not and or xor: for int and boolean
 
  
=== Modify variables (not implemented) ===
+
* Любые отсутствующие типы должны быть обнаружены (т.е. неизвестны какие-либо типы, которые не отображаются, если они не указаны в разделе «Проблемы fpc»
Not Done
+
* типы валют могут не отображать десятичную точку (они будут отображать значение * 1000)
 +
* Реализованы не все настройки из свойств окна наблюдений (большинство из них)
 +
* Выражения:
 +
** Отладчик принимает выражения, которые он будет вычислять. Не все операторы Паскаля реализованы.
 +
** Выражения рассчитываются без проверки диапазона
 +
*** простые выражения (просто идентификатор)
 +
**** Включает идентификатор значения 'self' (если в методе) и константы nil, true, false.
 +
*** приведение типов
 +
*** @ и ^ (address of и deref)
 +
*** "^TFoo(x)"' приведение типа x как указатель на TFoo
 +
*** () выражение в квадратных скобках "a*(b+c)"
 +
*** [] индекс для массивов, указателей и pchar
 +
*** Доступ участников к Foo.Bar
 +
*** постоянные числа в десятичном, шестнадцатеричном формате ($), oct (u0026), bin (%)
 +
*** постоянная строка (ansistring)
 +
*** + - * / для int и float
 +
*** мод для int
 +
*** + для строки
 +
*** +- для указателя + int
 +
*** div для int
 +
*** = <> < > <= >= для int, float, string
 +
*** not and or xor: для int и boolean
  
=== Console Output ===
+
=== Изменение переменных (не реализовано) ===
On Windows console is opened by OS.
+
Не сделано
On Linux the output goes to the debugger window "Console output"
 
  
=== Cross bit-ness Debugging (32/64 bit) ===
+
=== Консольный вывод ===
 +
В Windows консоль открывается ОС.
 +
В Linux вывод поступает в окно отладчика «Консольный вывод».
  
FpDebug has no cross debugging between different platforms.
+
=== Кросс-битовая отладка (32/64 бит) ===
 +
FpDebug не имеет кросс отладки между разными платформами.
  
However, if your IDE has a different bitness that your project FpDebug may be able to debug it.
+
Однако, если ваша IDE имеет другую разрядность, ваш проект FpDebug может ее отладить.
  
 
==== Windows ====
 
==== Windows ====
  
;A 64 bit IDE: can debug both 64bit and 32bit applications
+
;A 64-битная IDE: может отлаживать как 64-битные, так и 32-битные приложения
;A 32 bit IDE: can only debug 32bit applications
+
;A 32-битная IDE: может отлаживать только 32-битные приложения
 
   
 
   
 
==== Linux ====
 
==== Linux ====
  
Cross debugging has not yet been tested, but may be possible.
+
Перекрестная отладка еще не тестировалась, но, вероятно, возможна.
  
= Not implemented yet =
+
= Еще не реализовано =
  
* Modify watches
+
* Изменение окна отладки
* Changing Location of execution (while paused) / Resume execution from different line
+
* Изменение места выполнения (во время паузы) / возобновление выполнения с другой строки
* Properties
+
* Свойства
* Function calls
+
* Вызов функций
 
* ...
 
* ...

Latest revision as of 17:48, 17 August 2021

English (en) русский (ru)

О пакете

FpDebug - это отладчик, написанный языке Паскаль для использования в Pascal.

Подробнее:

  • FpDebug написан на Паскале
  • FpDebug использует формат отладочной информации DWARF
    • Текущая реализация является подмножеством DWARF с поддержкой DWARF версий 2 и 3. Однако «подмножество» - это просто состояние реализации. Цель состоит в том, чтобы расширить его, дабы реализовать как можно больше стандартных возможностей.
    • Текущая реализация охватывает подмножество, которое используется FPC
    • FpDebug имеет специальные реализации для работы с конкретным использованием DWARF для FPC (ошибки, отсутствующая информация, подробности реализации)

Что подразумевается под «FpDebug»

FpDebug может ссылаться на

Пакет "FpDebug"

Это движок отладчика. Это не относится к IDE. Пакет используется несколькими бэкэндами IDE:

  • Отладчик LLDB (с fpdebug): этот отладчик использует LLDB в качестве бэкэнда. Чтобы отображать результаты в стиле Паскаля, он использует движок «fpdebug» для отображения locals/watches.
  • Отладчик GNU (с fpdebug): для пошаговой отладки(stepping)/точек останова(breakpoints)/... используется GDB, а FpDebug - для списка слежения (watches).
  • Внутренний отладчик Dwarf FpDebug: "чистый" FpDebug. Пошаговая отладка(Stepping), Запуск(Running), Точки останова(Breakpoint), Список слежения (Watches), Локальные переменные (Locals), Стэк (Stack)....

FpDebug как ссылка на серверную часть IDE LazDebuggerFp

Фактическое имя серверной части IDE - LazDebuggerFp. Это имя пакета, который необходимо установить для использования отладчика. Однако, как видно выше, ни в каком техническом контексте (например, в заголовках в среде IDE) это не упоминается как «FpDebug ...»

Другие проекты FpDebug

Имя используется для другого проекта с той же целью.

Установка в IDE

Установите пакет LazDebuggerFp

Общие проблемы отладки

Эти проблемы не могут быть исправлены одним отладчиком. Им тоже нужны изменения в FPC. На некоторых может также повлиять отсутствие поддержки в DWARF.

Эти проблемы относятся ко всем серверным модулям отладчика.

Свойства

Свойства - одна из наиболее востребованных функций (любого) отладчика(ов). Вот почему они еще не могут быть проверены, и почему до этого пройдет еще немало времени.

Прежде, чем вдаваться в подробности: для «Свойства без getter-функции» (т.е. «с прямым доступом к полю») FPC (как средство решения проблемы) в настоящее время добавляет запись для переменной с именем свойства. Это означает, что такие свойства могут отображаться. Они также могут быть записаны отладчиком (если отладчик поддерживает изменение данных), и если они записаны, это делается в обход любой процедуры Setter, поскольку отладчик не знает, есть ли даже сеттер.

Есть несколько недостающих частей, позволяющих отладчику показывать (и, возможно, изменять) свойства.

  • Отладчику нужна поддержка для вызова функций.
  • FPC нужен способ добавить информацию о «свойствах» к отладочной информации.

Что касается вызова функции. Это просто может отсутствовать реализация в отладчике. Это еще не было исследовано более глубоко. Может потребоваться или не потребоваться дополнительная информация в DWARF, созданном FPC.

Что касается добавления «свойств» к отладочной информации: DWARF (по крайней мере версии 2 и 3 / не проверено 4 или 5) фактически не имеет возможности кодировать эту информацию. Следовательно, FPC в настоящее время также не добавляет его.

В случае, если DWARF не добавит это вовремя, DWARF позволит использовать данные от производителя (afaik). До сих пор ни один отладчик не знал бы о каких-либо «частных данных fpc», поэтому в этом не было никакого смысла. В будущем такие данные могут быть согласованы между FPC и FpDebug. Но до этого еще далеко. FpDebug еще даже не выполняет вызов функций.

Strings (vs PChar и Array of Char)

Первоначально в DWARF не было концепции кодирования строк. Это было добавлено в DWARF 4 (требуется проверка), но еще не исследовано на предмет удобства использования с FPC. Также в FPC в настоящее время реализованы только DWARF 2 и 3 (с первыми шагами к версии 4).

Остается только 2 способа кодирования строки в DWARF.

  • Как указатель на char
  • Как массив char

Какой из них используется, зависит от версии FPC и от того, используется ли DWARF 2 или 3.

Если это «указатель на char», то это делает его неотличимым от реального PChar. По этой причине все отладчики в Lazarus иногда для таких отслеживаемых выражений, как SomeString[4], показывают результат «PChar: 'a'; String: 'b'». Поскольку PChar начинается с нуля, а строка - с единицы, индекс «4» может означать 4-й или 5-й символ.

Недавние FPC используют «массив символов», когда они генерируются DWARF 3. В том, что у них (в настоящее время) есть различия в деталях реализации между тем, как они кодируют строки и реальный массив символов. (Например, пропуск необязательного/избыточного бита информации. В данном случае: DW_AT_byte_stride). Эти детали не имеют смысла с точки зрения любого другого отладчика, но FpDebug может их обнаружить, поскольку знает об этих деталях реализации. Конечно, это очень ненадежно, следующая версия FPC всегда может это изменить.

Аналогичным образом FPC обрабатывает ShortStrings внутри как запись и кодирует их как есть. Опять же, различие заключается в деталях реализации.

Изменение управляемых типов

Это применимо к любому отладчику, который может устанавливать новые значения для списка слежения (изменяет переменную в отлаживаемом exe).

Управляемые типы не могут быть изменены корректно.

Для изменения управляемых типов отладчику необходимо знать:

  • счетчик ссылок
  • копирование при записи
  • как выделить/освободить память / или лучше как вызвать методы inc/dec_ref для каждого типа, чтобы они выполняли работу правильно

Ничего из этого не доступно.

Если вы присваиваете новое значение строке или динамическому массиву, то необходимо скорректировать счетчик ссылок старого и нового значения. При необходимости память должна быть выделена или освобождена. Если это сделать неправильно, это, по крайней мере, вызовет утечку памяти. Но это также может вызвать сбои или другие случайные ошибки, когда отлаженный exe продолжает работу.

В массиве можно изменить один элемент. "SomeArray[5] := 7;". Если на массив ссылаются несколько переменных, это повлияет на их всех. То же самое произойдет, если вы выполните этот оператор в своем приложении.

У строки (AnsiString) использует механизм копирование при записи (copy-on-write). Если вы сделаете "SomeString[4] := 'a'", тогда переменная, из которой вы получили доступ к строке, получит новую копию, и другие переменные (которые совместно используют память) не должны быть затронуты. У отладчика этой информации нет. Также у него нет доступа к счетчику ссылок и распределению/освобождению памяти (или внутренним строковым процессам).

Вызов функции с управляемыми типами в качестве параметра или результата

Предполагая, что вызов функции был реализован в целом ....

По той же причине, что и в «Модификации управляемых типов», отладчик не может создавать строки или массивы для вызова функций, которые ожидают их как параметр.

Значения результатов можно принять, но это вызовет утечку памяти.

Область действия / порядок поиска переменных

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

Вложенные процедуры

var SomeVar: Integer; // глобальная переменная

procedure Outer(NumText: string);
var 
  SomeVar: Integer; // локальная переменная, объявленная выше "Nested"

  procedure Nested;
  var 
    I: Integer;
  begin
    WriteLn(OuterVarInScope);  
  end;

//var 
//  SomeVar: Integer; // локальная переменная, объявленная ниже "Nested"
begin
  Nested;
end;

Локальная переменная SomeVar скрывает глобальную переменную с таким же именем, если вы находитесь в процедуре «Outer». Локальная переменная также видна (и скрывает глобальную), если вы находитесь в процедуре «Nested».

Но если вы закомментируете локальную переменную, "объявленную выше Nested", и раскомментируете локальную переменную, "объявленную ниже Nested", то локальная переменная больше не будет в области видимости "Nested". «Nested» теперь будет видеть глобальную переменную. («Outer» по-прежнему видит локальные переменные).

Информация DWARF в настоящее время только сообщает отладчику, что SomeVar объявлена как локальная переменная в параметре "Outer". И это «Nested» находится внутри «Outer». Но информация DWARF не включается, если SomeVar объявлен выше или ниже "Nested". Так что отладчик не заметит разницы. В обоих случаях отладчик будет отображать локальную переменную SomeVar, если она приостановлена ​​в "Nested".


Глобальные перменные из других модулей

Информация DWARF содержит раздел для каждого модуля. Все символы модуля перечислены в правильном разделе. Однако нет информации о том, какой модуль входит в секцию "uses" какого другого модуля. И, очевидно, даже меньше, в каком порядке они используются.

Если существует несколько глобальных переменных с одинаковым именем, по одной в каждом из нескольких модулей, то FPC использует порядок разделов uses (справа налево), чтобы найти переменную, которая будет видна из кода в текущем модуле.

Если в модуле FooBar есть код, который обращается к переменной с именем NotInFooBar (которая не объявлена ​​в модуле FooBar), то эта переменная должна быть из одного из других модулей. Если есть несколько переменных с именем NotInFooBar в разных модулях, то отладчик не имеет информации, какой из них именно использовал FPC. В настоящее время отладчик показывает первое найденное. (Что вроде случайно)

Проблемы FPC

Это влияет на все отладчики

  • resourcestring

В настоящее время не реализовано https://bugs.freepascal.org/view.php?id=35571

  • const Foo = unicodestring('abc')

Информация об отладке не реализована https://bugs.freepascal.org/view.php?id=35569

  • type Foo = object (Dwarf 3) - Исправлено в 3.3.3

Неправильно закодирован как экземпляр класса https://bugs.freepascal.org/view.php?id=36017
Отладчик не может отобразить данные.

  • Динамический массив при кросс-компиляции

https://bugs.freepascal.org/view.php?id=35567
Отладчик может неправильно вычислить длину.

  • Неправильный шаг для битового массива - исправлено в 3.3.3

https://bugs.freepascal.org/view.php?id=36144
В настоящее время у FpDebug есть обходной путь

Положение дел

FpDebug поддерживает Linux, Windows и MacO.

Любые функции, касающиеся управления выполнением (пошаговое выполнение/приостановка ...), тестируются только для Linux и Windows. Поддержка этого на Mac неполная/ненадежная.

Light bulb  Примечание: Для Windows/Linux см. Debugger Status

Поддержка Mac в настоящее время считается «альфа-версией» Оценка данных может использоваться на Mac через серверную часть LLDB + FpDebug

Информация носит ориентировочный характер и может обновляться / подлежит дальнейшему тестированию.

Примечания

Пошаговый вывод

«Пошаговый вывод» основан на поиске адреса вызова. Расположение которого зависит от того, есть ли у функции «стековый фрейм» (использует регистр BasePointer и (прим. перев.: представляет из себя структуры в стеке процессора)) и имеет ли уже/все еще настроенный фрейм. Обнаружение этого ограничено несколькими стандартными ситуациями. (Особенно это невозможно обнаружить в коде FPC или в оптимизированном коде).

Эта функция работает в неоптимизированном коде FPC.

Аппаратные точки наблюдения (также известные как точки останова по данным)

Частично реализовано для большинства типов данных (подмножество типов, поддерживаемых оборудованием), включая условия и другие свойства.

Все точки наблюдения будут иметь глобальную область действия. Наблюдение за локальной переменной будет предупреждать вас в следующий раз, когда память переменной будет перезаписана (например, если другая переменная займет память).

Точки наблюдения "только запись" действуют как "чтение/запись"

Точки наблюдения также срабатывают, если они перезаписываются имеющимся у них значением.

Точки наблюдения не показывают диалоговое окно до/после.

Точки наблюдения, которые не выровнены по адресу, кратному их размеру, могут запускаться соседними значениями. Например, Word, начинающееся с нечетного адреса, может запускаться байтом до или после него. 64-битный указатель должен быть выровнен по 8-байтовой границе или может запускаться соседями.


Поток и стэк

См. «Пошаговый вывод». Полагается на то же обнаружение кадров.

Окно наблюдений / Локальные переменные / Осмотр

Реализовано

  • Любые отсутствующие типы должны быть обнаружены (т.е. неизвестны какие-либо типы, которые не отображаются, если они не указаны в разделе «Проблемы fpc»
  • типы валют могут не отображать десятичную точку (они будут отображать значение * 1000)
  • Реализованы не все настройки из свойств окна наблюдений (большинство из них)
  • Выражения:
    • Отладчик принимает выражения, которые он будет вычислять. Не все операторы Паскаля реализованы.
    • Выражения рассчитываются без проверки диапазона
      • простые выражения (просто идентификатор)
        • Включает идентификатор значения 'self' (если в методе) и константы nil, true, false.
      • приведение типов
      • @ и ^ (address of и deref)
      • "^TFoo(x)"' приведение типа x как указатель на TFoo
      • () выражение в квадратных скобках "a*(b+c)"
      • [] индекс для массивов, указателей и pchar
      • Доступ участников к Foo.Bar
      • постоянные числа в десятичном, шестнадцатеричном формате ($), oct (u0026), bin (%)
      • постоянная строка (ansistring)
      • + - * / для int и float
      • мод для int
      • + для строки
      • +- для указателя + int
      • div для int
      • = <> < > <= >= для int, float, string
      • not and or xor: для int и boolean

Изменение переменных (не реализовано)

Не сделано

Консольный вывод

В Windows консоль открывается ОС. В Linux вывод поступает в окно отладчика «Консольный вывод».

Кросс-битовая отладка (32/64 бит)

FpDebug не имеет кросс отладки между разными платформами.

Однако, если ваша IDE имеет другую разрядность, ваш проект FpDebug может ее отладить.

Windows

A 64-битная IDE
может отлаживать как 64-битные, так и 32-битные приложения
A 32-битная IDE
может отлаживать только 32-битные приложения

Linux

Перекрестная отладка еще не тестировалась, но, вероятно, возможна.

Еще не реализовано

  • Изменение окна отладки
  • Изменение места выполнения (во время паузы) / возобновление выполнения с другой строки
  • Свойства
  • Вызов функций
  • ...