On 2026-05-27 12:42, Martin Frb via fpc-devel wrote:
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] := '?';
Yes, but there is an important difference there. If there's code
modifying the value, this code uses this copy from that point on.
However, if a user wants to modify some data in a debugger, this user
probably wants to do it in order of his code started to use the new
value instead of the original value, not because of being interested in
having another copy of the original data with a different value (which
wouldn't be used by the debugged code any longer).
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.
Yes - it's absolutely appropriate for the debugger to be aware of the
refcounting and warning the user if the reference counter is higher than
1 and the user intends to modify the value.
---------------
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)
Yes, I don't want to question the necessity of understanding the
refcounting for the debugger.
And trying to detect that based on coincidental other criteria.... not
the best idea.
Correct.
.
.
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.
Yes, peeking the refcount may be indeed useful, that's for sure.
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.
Function calls in watches are very tricky in any case and allowing them
in case of reference counted parameters sounds like a recipe for
problems as far as I can tell (I can imagine quite a few cases when this
may lead to complete change of the behaviour of the program being
debugged). If nothing else, the debugger should warn the users trying to
do that.
Tomas
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
