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

Op 13-10-2019 om 00:22 schreef Martin:

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

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.

That some debuggers, specially made for fpc (like fpdebug, but in some regard this holds for gdb too) show a more convenient format, is nice. But I think this is not relevant for the compiler.

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.

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.

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.

Regards,

Joost.

I am away this week, I check next week.

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

true, I have one for now ...

could you explain?

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.

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)

There is a project for manual testing:
components\lazdebuggergdbmi\test\RunGDBMI.lpi

It reads a list of fpc compilers from fpclist.txt (there is a sample file).  And gdb versions from gdblist.txt.
It then takes an exe, that it will compile and run to a breakpoint. There it will send a series of gdb commands, and record the results. It can record them in csv format (copy and paste to libre office calc)

File: full filename with path - to be compiled
break: file without path, in which to set the breakpoint (can be used unit) checkbox "csf": comma separated
upper memo: commands for gdb, one per line
lower memo: output

I tested the following
   a1: array of ansistring;
   a2: array of array of ansistring;
   s1: array [3..5] of ansistring;
   s2: array [3..5, 7..8] of ansistring;

with 3.0.0 (32bit only),  3.0.4, trunk 43310, and 3.2.0 43184  / dwarf (with sets) and dwarf3
sending to gdb (32bit 7.2,  7.7.1,  7.8.2,  8.2.0   and 64bit 7.3-5,  7.7.0,  7.8.2,  8.2.0):
p a1
p a2
p s1
p s2

results attached (as libre office calc)

static array with dwarf-2 work.
In any case I see no change in the results depending on fpc version (so the recent fixes made no diff for gdb)

If you remember what you tested, then I can run that against newer versions.