On 27/05/2026 14:27, Tomas Hajny via fpc-devel wrote:
On 2026-05-27 13:45, Martin Frb via fpc-devel wrote:
procedure DoFoo(s: AnsiString);
begin
...
// paused here
...
if s = ... then
...
end;
....
Then that user most likely does not want the variable in the caller
to be changed?
Actually, I'd expect that _if_ the user wants to modify the value
within the debugger, he wants to have full picture of effects of the
modified value rather than just parcial effect which would never match
real case scenario when the variable has a different value. Moreover,
creating a copy for the modified version wouldn't change the reference
used in the code of DoFoo, would it? Otherwise you'd need to modify
not only the value, but also all parts of code in DoFoo retrieving
this value to point to the new copy instead, right?
Yes, the idea would be that telling the debugger do "set s[1] to be '?'"
would
- check the refcount
- if 1 => then modify directly
- if 2 or greater => then
- create a new string in the target memory
- change the char
- point "s" to that new string
- decref the old string
// all this could alternatively be a call to "uniquestring" followed
by the modification
And that would also deal with a refcount of -1 (a VARIABLE, but pointing
to a constant string) => which should probably ask by default.
If that is done, then the code in "DoFoo" would continue, and "s" would
have the new value.
But the caller would still the unmodified value.
---------------------
Also I completely forgot (and currently IIRC the debugger rejects it
entirely)
Tell the debugger to modify: MyAnsiStr := 'abc'
Then the old value needs a decref, and a new string must be created.
But if it isn't refcounted, then the old value must not be touched, just
the new one needs to be allocated in mem, and pointed to)
// and well that may leak, if the user doesn't know what they do...
---------------------
Generally we have 2 kind of users (more, but lets simplify)
1) the beginner-like user
Someone who might not even know that FPC uses copy on write.
Someone who truly thinks that after "s1 := s2;" they have 2 completely
unrelated values.
2) the experienced user
Someone who knows what happens under the hood, and may make use of that
within their code. And of course during debugging.
----------------
Currently, in the few cases where FpDebug can detect an AnsiString as
such (Dwarf-3), it can handle it in function calls (definitely as
result, iirc as param too, including from constant in the user
expression).
And FpDebug does do the correct additional calls to the rec cnt
functions. (via the linker symbols, that usually are available)
Adding the tag will ensure FpDebug can more accurately/safely detect
such strings.
OK, that indeed makes sense.
Well, and hence, back to my original question...
Any ideas what I should consider when formulating a feature request for
additions to the DWARF standard.
And for that, the idea is to make sure that
=== The information can be added to debug info should that be needed ===
Once it can be added, we can still decide
- what we add
- how we use it
I want to avoid requesting it now, and then find that I forgot some.
E.g. I forgot that you can have properties like
TFoo = class
FList = array [0..9] of TPoint;
property X2: integer read Flist[2].x; // yes, that works
end;
That doesn't even need function calls..
=> well that can be encoded as workaround "tag_member x2" / but then
looses the info its a property
the DW_TAG_property support the field ".x", but not the index on the
field var. (it supports other indices)
-------------------------------
So how are ref counts used with e.g. smart pointers.
What data types will there by in smart pointers
What operations happen on smart pointers and there data
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
