[Lazarus] Debugging the unicode RTL

[Martin Frb]

On 22/01/2023 11:53, Michael Van Canneyt via lazarus wrote:
>
> 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.

if adding a watch containing  "^char(x)" fails, then that will upset 
plenty of people. (including me)

That alias should always be encoded as type, if it is used in the user's 
code.


> 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.

Not really.

Whenever the debugger accesses "char" or "sequence of char" data, it 
should have debug info for this.
If it has, this debug info will contain the size-of for that/those chars.
And that is enough to decide if that particular instance is utf8 or utf16.

If the RTL (or user code) would be partly AnsiChar, and partly 
UnicodeChar... => no problem.

The problem is, that the Exception.FMessage is not using dwarf info. 
(Because it is not always included)

>
> 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.

Well if it is not possible to include
     type sysutils.Exception
in the dwarf info,
then some other kind of flag needs to be agreed that is on top of the 
normal dwarf.

The question is where to store this.
- It could be some $$$char  type declaration (to make sure it can't 
clash with user names). But then should be in a specific unit, so the 
debugger knows where to look.
- It could be an addition to the "producer" in the Compilation-unit (but 
that needs to be repeated in every CU)
- It could be a "linker symbol" like FPC_RAISEEXCEPTION",
   where the compiler either includes FPC_CHAR_IS_ANSI or FPC_CHAR_IS_UNI

Or, depending on how the whole stuff works with the linker....
Even if sysutils.o does not have debug info, the compiler could write 
and include a dummy .o file that has debug info and gets included.
It may have to use a diff unit name for that: sysutils$$fpc.o


Those are just ideas, I don't know the compiler/linker well enough....

Any "global" flag, will cause extra work when it comes to dll/libraries. 
Because then all FpDebug code needs to handle this per dll.