[fpc-devel] 0036144: Wrong Dwarf2/3/4 info for array (all array, but affects bitpacked) / incorrect use of DW_AT_bit_stride

Martin Frb lazarus at mfriebe.de
Wed Oct 23 13:15:26 CEST 2019


On 23/10/19 11:34, Joost van der Sluis wrote:
> Op 13-10-2019 om 00:22 schreef Martin:
>> - ShortString are encoded exactly as
>> record  len: int;   st: array of char;  end;
>> - And in dwarf 3, ansistring are encoded as array. .
> Well. If someone creates a record called 'ShortString', (s)he should 
> not be surprised that the debugger thinks that it is actually a 
> shortstring?
>
> I do not see the issue here. The compiler generates debug-information 
> that makes it possible for any debugger to show the data correctly. 
> For shortstrings it repors a structure with a length and the actual 
> characters. This is what a shortstring is..

A user may copy a watch expression from its source (when using mouse 
hint, but also instead of typing a copy to the watch window). That may be
    FooString[5]

If shortstring is a record (gdb without help from the IDE) then the 
watch fails, because it must be FooString.st[5]

Of course this is not a problem in the IDE since the IDE can change it, 
and may even do so for a userdefined record.
Though FooString [0] should only work for shortstrings. (to get the len)

The problem is more severe in cases (dwarf2) where ansistring and pchar 
are indistinguishable. Because s[1] can be the 1st or 2nd char.... And 
that means WRONG data can be displayed.

In dwarf3 it is array of char vs ansistring.
And while ansistring should usually display utf8 as text, array of char 
is on "8bit" char at a time. (IMHO)


More information about the fpc-devel mailing list