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

[Martin Frb]

On 23/10/19 11:34, Joost van der Sluis wrote:
> Op 13-10-2019 om 00:22 schreef Martin:
>> I have a few wishes with regards to: 
>> https://bugs.freepascal.org/view.php?id=36144
>>
>> 1)
>> FpDebug detects fpc as dwarf provider, and checks the fpc version. 
>> Based on this it can interpret the misplaced tags, and work around 
>> the issue.
>> I have now configured 3.3.0 as the cut-off for the workaround (since 
>> fpc now puts the tags in the correct location).
>>
>> Should this patch get merged to 3.2 then please alert me of this. So 
>> I can adjust the check in FpDebug.
>
> About the patch: I made the original change within the period that I 
> tried to get multiple-dimensional arrays to be displayed correctly in 
> gdb. Especially arrays of ansistrings. In the end this worked, does 
> this still work?
>
> We need some kind of debug-tests. I know you have some, and that there 
> are huge differences between gdb versions, but still...

I am away this week, I check next week.


>
>> 2)
>> "I shot myself in the foot"
>> Having reported this issue, and it no being fixed, I realized that I 
>> (ab)used the presence of this issue.
>>
>> - ShortString are encoded exactly as
>> record  len: int;   st: array of char;  end;
>> - And in dwarf 3, ansistring are encoded as array.
>>
>> With the only difference that they always had the stride in the 
>> array, and not in the range.
>>
>> FpDebug used the knowledge of this implementation detail (in the hope 
>> that it would not change) to detect the diff between a user defined 
>> record (with the exact same fieldnames), and an actual shortstring.
>> That no longer works....
>
> 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.
>
Yes it is correct right now.

But it might be possible to improve, since dwarf has a string type, and 
all we (or I) need to test is if gdb (nowadays) can display it.

shortstring might still be a record, though...

Btw shortstring has 2 length...
type s = string[20];

can hold 20 chars (important if the debugger wants to change the value)
but
   s:='abc'
sets the length (s[0]) to 3


>
>> So I need a new difference, please.
>
> Adding an artificial difference (some sort of implementation-detail) 
> on which some debuggers depend, does not seem to be a good idea, imho.
>
true, I have one for now ...

>> Ideally using DW_TAG_string_type (available since dwarf 2).
>> I have currently no idea what gdb will do with that.
>> For FpDebug I will have to implement it, but that is no problem.
>
> DW_TAG_string_type is deliberately not used, as it describes a 
> string-type that fpc does not use.
>
could you explain?

>
> If the stride is optional, the compiler should always omit it when not 
> necessary, to decrease the executable (debuginfo) size. What you ask 
> is to add a bug deliberately, which you can use to detect whether 
> something is a string or not. 
True. I am not fond of implementation detail stuff....

But I would very much like a definite specification

fpc has -godwarfcpp
it could have godwarffpd
and then use vendor tags, to describe any pascal type that has no exact 
dwarf spec.


fpdebug knows the fpc version that wrote the dwarf. so for older fpc it 
can use the implementation details (they do not change). And if we can 
start and work out proper details for the future then that will solve it.