[Lazarus] Debugging the unicode RTL

[Michael Van Canneyt]

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 
>> size.
>>
>
> 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 
>> code,
>> 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.

Michael.