<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/01/2019 11:20, Joost van der
Sluis via lazarus wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2e79a8a5-8aee-dd2b-7436-711ac54e7081@cnoc.nl">Op
09-01-19 om 09:40 schreef Dennis via lazarus:
<br>
<blockquote type="cite">When I tried to debug with fpdebug, it
asked me
<br>
<br>
Which one should I choose?
<br>
</blockquote>
<br>
I saw this screen also, and was quite confused. As far as I know
fpc uses Dwarf as default now. But Martin probably had a reason to
add this.
<br>
</blockquote>
<br>
Fpc 3.0.4 with -g on win 32bit => stabs <br>
<br>
The IDE makes no assumption what -g means. So it asks. It also asks,
if you have no debug info switched on at all. (Despite that is only
the project, and packages might have dbg info...)<br>
<br>
<blockquote type="cite"
cite="mid:2e79a8a5-8aee-dd2b-7436-711ac54e7081@cnoc.nl">
<br>
Select -gw3. It basically means that the compiler is allowed to
use Dwarf-3 specific functions. (In practice: proper string
indexing, so 1-based instead of 0-based.) Older versions of Gdb
did not handle those properly.
<br>
</blockquote>
New versions of gdb still crash with PAnsiString under dwarf3 (But
that is gdb and off topic)<br>
<br>
<blockquote type="cite"
cite="mid:2e79a8a5-8aee-dd2b-7436-711ac54e7081@cnoc.nl">
<br>
Otoh, it could be that Martin added work-arounds for the string
issues with Dwarf-2. But this all has to be tested. ;)
<br>
</blockquote>
Only for cases that can be detected => that is short string<br>
AnsiString are handled as pchar => #0 terminated (there is on
diff in the dbg info, so not possible to determine)<br>
AnsiString[n] returns 2 results: 0 and 1 based<br>
<br>
<blockquote type="cite"
cite="mid:2e79a8a5-8aee-dd2b-7436-711ac54e7081@cnoc.nl">
<br>
So I would say, use the newest version, Dwarf 3, -gw3.
<br>
</blockquote>
<br>
Yes Dwarf 3 is recommended for fpdebug (You also get the benefit of
identifiers NOT being all uppercased)<br>
<br>
A few notes:<br>
<br>
Evaluating of <span class="bbc_u">local var</span> and <span
class="bbc_u">param</span> while paused on procedure/function <span
class="bbc_u">begin or end line</span> may cause crashes.
(especially with Dwarf 3)<br>
This applies to Locals/Watches/Evaluate/... views.<br>
Currently the problem is know for variable len type data (string/dyn
array), including structures containing such types.<br>
See <a href="https://bugs.freepascal.org/view.php?id=34746"
class="bbc_link" target="_blank">https://bugs.freepascal.org/view.php?id=34746</a><br>
A <strong>workaround </strong>(for currently known cases) is
present. (r59895) <br>
<br>
(Any Dwarf version) Strings and Arrays are limited to a max len of
5000 / 3000. Currently this is not configurable. Sometimes less.
Nested arrays are limited to just the first few items. <br>
This is partly an "out of mem" protection, and also a limit needed
by the lldb-fp debugger for Mac (reading huge mem takes long time)<br>
<br>
PChar, WideStrings, (maybe AnsiString in Dwarf 2) may be cut off,
even if below there max len limit. The Debugger sees WideString as
PWideCHar and has to guess how far to look for the terminating #0.
The guess is adjusted in steps, and may miss the correct len<br>
=> For WideString fpc does not yet use the dwarf3 encoding with
length.<br>
<br>
With Dwarf 2 all strings are #0 terminated (strings are pchar).
Except shortstring, which are encoded as record, but recognized by
fpdebug and displayed correctly.<br>
<br>
<br>
</body>
</html>