Recent

Author Topic: Lazarus Release Candidate 2 of 2.2.0  (Read 23284 times)

Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #75 on: November 29, 2021, 06:33:21 pm »
GDB has lots of issues with various Pascal data types and structures. Depending on the gdb version this leads from data not shown to crashes.

many thanks for all your info. That helped me a lot!

My mistake was to use the FPCUPDeluxe version and leaving the official RC2 installed version aside. With FpCUPdeluxe one has to setup GDB on its own when necessary.

The last days then I debugged with FPDebug and I noticed that in some data structures I could not read out the values while this worked with GDB. I also got crashes with GDB in the past, but not often. For me the info about the actual values is more important that I will stay a while now with GDB.

You also helped me to understand the different debugger options, so I will now try out dwarf3 and see if this is a benefit.

I will not go back to the official RC2 release to not report here things that are actually not in RC2.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7522
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #76 on: November 29, 2021, 06:49:50 pm »
The last days then I debugged with FPDebug and I noticed that in some data structures I could not read out the values while this worked with GDB. I also got crashes with GDB in the past, but not often. For me the info about the actual values is more important that I will stay a while now with GDB.

Do you have examples for the missing fields?
(and your OS / and which debug info type)

I know of the following (some only from having been told...)

- "file of FOO"
If (and only if) compiled with stabs, then a lot of details (like the file handle) will be visible.
Since it is stabs, it is gdb only.

- variant (and maybe records with "case" section)
FpDebug does not show the data, if dwarf-3 is used. Should work with Dwarf-2.

- type foo = interface
does not work, because there is no data in the interface (and the debug info does not contain anything about it => so not debugger specific)

- mode delphi - automatic dereferencing
   Type foo = ^record a: integer; end;
I have no idea if (by mere accident) "FooData.a" will work in gdb. (Since gdb itself has issues with getting Pascal data with (hidden) pointers in some cases, the IDE does a lot of trickery to get the data => it might just solve this, without intend / never tested)
FpDebug will not resolve "FooData.a" => there is a {$DEFINE } that can be set to compile the IDE, and then it will work.


Also make sure that packages are compiled with Dwarf. They are often set to automatic. Afaik that only matters for some 32bit targets, on 64 bit major targets the fpc default should be dwarf anyway.
« Last Edit: November 29, 2021, 06:54:18 pm by Martin_fr »

Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #77 on: November 29, 2021, 07:26:40 pm »
Do you have examples for the missing fields?
(and your OS / and which debug info type)

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-63-gc29da8f0d8)
FPC 3.2.3 x86_64-win64-win32/win64
Windows 10 21H2, 64bit

I tested with dwarf with sets, dwarf2 and dwarf3.

In the attached image is my test case.

This is a simple int and I don't understand why I don't see its value. Here is the source code: https://github.com/JobstTechnologies/JT-Driver-Sensing/blob/master/SIXControlUnit.pas#L71

(I tried to set up gdb for comparison but failed since GDB crashes now all the time -> I really need t go away from the FCUPDeluxe build.)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7522
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #78 on: November 29, 2021, 10:48:07 pm »
I tested with gdb, and did also not get them with gdb (9.2).

Those are "class var" => basically global, but scoped. So to avoid naming conflicts, fpc renames them and tells the debugger they are called
dwarf2:  _static_tsixcontrol_NUMCHANNELS
dwarf3:  $_static_tsixcontrol_NUMCHANNELS

At least, fpc kept the var name uppercase even in Dwarf3 (were it normally uses the case as in the source).

So it should be (almost) possible to find them.

Only issues would be

1)
with dwarf2
Code: Pascal  [Select][+][-]
  1. var _static_tsixcontrol_NUMCHANNELS: integer;
would be detected as static var, but is not.

2)
Code: Pascal  [Select][+][-]
  1. type
  2.   TFoo_ = class
  3.     class var
  4.     bar: integer;
  5.   end;
  6.  
  7.   TFoo = class
  8.     class var
  9.     _bar: integer;
  10.   end;
  11.  
But that fails to compile: project1.lpr(25,3) Error: Duplicate identifier "$_static_tfoo__BAR"

Need to see how soon I can get to this....

Bart

  • Hero Member
  • *****
  • Posts: 4513
    • Bart en Mariska's Webstek
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #79 on: November 29, 2021, 11:06:39 pm »
Code: Pascal  [Select][+][-]
  1. type
  2.   TFoo_ = class
  3.     class var
  4.     bar: integer;
  5.   end;
  6.  
  7.   TFoo = class
  8.     class var
  9.     _bar: integer;
  10.   end;
  11.  
But that fails to compile: project1.lpr(25,3) Error: Duplicate identifier "$_static_tfoo__BAR"

That's a real nice bug if I may say so  O:-)

Bart

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7522
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #80 on: December 01, 2021, 10:09:40 pm »
I tested with gdb, and did also not get them with gdb (9.2).

Those are "class var" => basically global, but scoped. So to avoid naming conflicts, fpc renames them and tells the debugger they are called

Partly fixed (main and fixes branch).

Evaluating (watch or hint) "NUMCHANNELS" while in a method of the class should work.

TClass.NUMCHANNELS  will not yet work, neither inside any method of the class, nor from code outside.  (same for instance.NUMCHANNELS)

I also have yet to test, if it works across unit bounds, if the var is in an ancestor in a diff unit.

avra

  • Hero Member
  • *****
  • Posts: 2262
    • Additional info
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #81 on: December 01, 2021, 10:24:38 pm »
FpDebug will not resolve "FooData.a" => there is a {$DEFINE } that can be set to compile the IDE, and then it will work.
Could you remember which exact define it is, and why it is not switched on by default?
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7522
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #82 on: December 01, 2021, 10:32:01 pm »
FpDebug will not resolve "FooData.a" => there is a {$DEFINE } that can be set to compile the IDE, and then it will work.
Could you remember which exact define it is, and why it is not switched on by default?
FpDebugAutoDerefMember

Commandline:
-dFpDebugAutoDerefMember

Afaik in mode objfpc that behaviour is also off.
I haven't checked if it is in any way possible that an expression could be ambiguous with this on.
I don't use it myself for writing code. So the first thing I would not know is
Code: Pascal  [Select][+][-]
  1. type
  2.   TIntArr = array of integer;
  3.   PIntArr = ^TIntArr;
  4. var
  5.   a: PIntArr;
  6. begin
  7.   if PtrUInt(a[1]) <> 0 then
  8.  
Would that access the first element in TIntArray?
Or would that use pointer math, and mean (a+1)^ the pointer to the 2nd (index 1) of many TIntArray stored at the address to which a points?

IIRC, fpdebug currently checks first if the expression is valid without auto-deref, and then falls back. So IIRC it would go for the 2nd answer. But not sure.

Also since I don't use the feature in coding, and I haven't yet spent time on reading up on all the possibilities how it could be used, I don't know if fpdebug covers every case, or just some.


---

The idea is to make it a configurable option in the IDE options. But I haven't gotten to that yet.

And no: the debugger does not know what mode switches were given. Not part of the debug info.
« Last Edit: December 01, 2021, 10:45:19 pm by Martin_fr »

PascalDragon

  • Hero Member
  • *****
  • Posts: 3515
  • Compiler Developer
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #83 on: December 02, 2021, 09:06:21 am »
I don't use it myself for writing code. So the first thing I would not know is
Code: Pascal  [Select][+][-]
  1. type
  2.   TIntArr = array of integer;
  3.   PIntArr = ^TIntArr;
  4. var
  5.   a: PIntArr;
  6. begin
  7.   if PtrUInt(a[1]) <> 0 then
  8.  
Would that access the first element in TIntArray?
Or would that use pointer math, and mean (a+1)^ the pointer to the 2nd (index 1) of many TIntArray stored at the address to which a points?

As auto dereferentiation comes from Delphi one point to keep in mind is that Delphi does not support indexing pointers using the array syntax. So without auto dereferentiation (which can't be switched off in Delphi) a[1] would be invalid code. So the only valid case is that it is essentially a^[1]. And lo and behold, that's how it's implemented in FPC.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7522
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #84 on: December 02, 2021, 01:10:05 pm »

As auto dereferentiation comes from Delphi one point to keep in mind is that Delphi does not support indexing pointers using the array syntax. So without auto dereferentiation (which can't be switched off in Delphi) a[1] would be invalid code. So the only valid case is that it is essentially a^[1]. And lo and behold, that's how it's implemented in FPC.

And so, autoderef in FpDebug must be off by default.

Because then

Code: Pascal  [Select][+][-]
  1. type
  2.   TIntArr = array of integer;
  3.   PIntArr = ^TIntArr;
  4. var
  5.   b: array of TIntArr;
  6.   a: PIntArr;
  7. begin
  8.   SetLength(b, 2);
  9.   a := @b[0];
  10.  
  11.   a[1] ....
  12.  

"a[1]" returns the value of b[1]

While with autoderef it returns b^[1] => which is b[0][1]

---
All that, once it is fully and correctly implemented in FpDebug.

 

TinyPortal © 2005-2018