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

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

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

So I need a new difference, please.

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.

If that is not an option, can we go for a simpler (implementation detail 
(yes again)) workaround (that then goes into trunk, and/or if the 
original fix is merged, can be merged too):
- The stride is optional. If absent it is equal to the element size 
(shortstring = char = byte)
- Arrays always have a stride
- Drop it from the strings array
And I can then detect that.

---
Open for other ideas