On 27/05/2026 12:29, Tomas Hajny via fpc-devel wrote:
On 2026-05-27 12:11, Martin Frb via fpc-devel wrote:
I know how refcount internally work on strings and dyn array.
I am thinking about formulating a request to the DWARF specs. So I
want to check the details, and also get information how they
- will work for smart pointers,
- where else they may occur?
Background, refcounts may be of interest for the debugger in at least
the following cases.
- A user modifies a variable (or an indexed value) via the debugger.
~ The debugger may additionally need info, if it should "copy on
write" / though that can be derived....
~ The debugger could inform the user about "side effects on other
references to the value"
.
.
I can't imagine a reasonable scenario when a user might want to
perform a modification of a refcounted variable of the program being
debugged by using "copy on write".
If the user assigns a new (char) value to
MyAnsiString[3]
then they might expect that.
After all, this is what would have happened, had there been code doing
MyAnsiString[3] := '?';
At that point, a user might not even remember that the text content of
MyAnsiString may use the same memory as some other string var that they
have.
For dynamic arrays, of course the correct behaviour is to modify all
variables that share the memory. Same as we do with objects (class
instances), for which there isn't ever a refcount and it couldn't even
be known.
---------------
So for copy on write: this is about ansistrings. But the debugger must
know that it has a refcounted string. => and e.g for wide-types there are
- widestring (afaik not refcounted on Windows)
- unicodestring (refcounted)
And trying to detect that based on coincidental other criteria.... not
the best idea.
I strongly believe that such an option should not be offered to the
user at all. As far as modifying the already existing instance is
concerned, the debugger should probably always check whether the
shared reference is still valid and having the original value at the
time of trying to modify it - trying to add the debugger as another
reference of an existing refcounted variable might IMHO lead to
unexpected/unwanted effects on the program being debugged and thus
should be avoided as well.
As for the new smart pointers, I haven't played with them yet.
I don't expect that there will be any special behaviour on the debugger
side for the "modify" feature.
But....
1) The debugger has the :ref intrinsic that currently allows the user to
peek at the refcount of string and dyn-array => that can be useful.
I could imagine if you have leaks with smart pointers, then you may want
to trace this.
2) The debugger may need to create/destroy data, if it passes it to
function calls in watches (or dec-ref results).
So it does need to know if there is a ref-count.
Once it knows the type is refcounted, it should hopefully be able to
decide the correct function based on knowing what the compiler does for
a given type.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
