[Lazarus] Debugging the unicode RTL
Michael Van Canneyt
michael at freepascal.org
Sun Jan 22 11:53:18 CET 2023
On Sun, 22 Jan 2023, Martin Frb via lazarus wrote:
> On 12/01/2023 11:26, Michael Van Canneyt via lazarus wrote:
>> It needs to determine the definition of "string" which will be an
>> array of
>> unicodechar or ansichar. Once it knows that, the rest will follow,
>> since the definition of unicodechar or ansichar will have the correct
> The big issues is still, that dwarf does not make any
> (official/documented) diff between PChar, string and array of char.
> Except for internal encoding details ....
Since the PChar/Char types are now an alias, logically the debug info
should only have references to AnsiChar/UnicodeChar.
But I have no idea how to test this assumption.
>> I don't think this is a very reliable method. In moderately difficult
>> half of the time the codetools don't work properly, so relying on them
>> to provide this info is a recipe for disaster. Hence my question...
> The debugger does and should not relay on codetools.
> Well, there is a case where codetool helps preparing....
> If you add a watch (or hover for a hint), codetool will determine the
> boundaries of the expression.
> So "foo.bar" will not just add bar, but the correct term.
> Or "foo.bar[x.y]" if you hover on y, will get x.y, but if you hover
> on "]" will get the full term.
> And codetool will resolve "with" at that time.
> But that is it.
> And it should be it.
We are 100% agreed on that, hence my questions.
So, if I understand you correctly:
The problem is now to see if the debugger can determine from the
available debug info/rtti whether the RTL uses AnsiChar or UnicodeChar.
Which still leaves the question:
What to do if there is no debug info for the system unit ?
By default, FPC distributes units without debug info.
As far as I know, TObject does not have any RTTI associated with it.
More information about the lazarus