Recent

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

Muso

  • Sr. Member
  • ****
  • Posts: 356
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: 9754
  • 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

  • Sr. Member
  • ****
  • Posts: 356
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: 9754
  • 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: 5265
    • 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: 9754
  • 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: 2514
    • 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: 9754
  • 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: 5444
  • 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: 9754
  • 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.

Muso

  • Sr. Member
  • ****
  • Posts: 356
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #85 on: December 06, 2021, 03:51:12 am »
Partly fixed (main and fixes branch).
Evaluating (watch or hint) "NUMCHANNELS" while in a method of the class should work.

I got the latest 2_2 fixes branch and tested it. It works fine for me.  :)
Many thanks!
(I am also impressed how quick you implemented this.)

Muso

  • Sr. Member
  • ****
  • Posts: 356
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #86 on: December 06, 2021, 06:49:20 pm »
@martin_fr I see now another debugger issue that should be improved for the final release

- in the Project Options I set to use FPDebug, see the attached screenshot
- this results in this change in the *.lpi file

Code: Pascal  [Select][+][-]
  1. <Debugger>
  2.       <Backend Value="{9983401B-BBC1-4101-B04B-D600E4AB6D20}"/>
  3. </Debugger>
  4.  

OK, but when I now open the *.lpi file on another PC, I get a warning that the debugger was not found.
When I set on this PC FPDebug and transfer it back to the initial PC, I get the same warning. So I think the Backend Value should maybe simply be "FPDebug" and no number that might not exist on another PC.
« Last Edit: December 06, 2021, 06:53:54 pm by Muso »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #87 on: December 06, 2021, 07:37:26 pm »
Please report on the bug tracker. That should probably be stored in the session.

It needs to be an UUID reference.

For example in my IDE, I hav many "gdb" debuggers defined. For testing diff gdb versions.
If FpDebug will have more options, maybe some people want several configs.

So just "FpDebug" is not possible. Which of the many configs would that be?

---
There is more that needs to be added  to the abilities of setting and choosing debuggers. But all in good time.

Muso

  • Sr. Member
  • ****
  • Posts: 356
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #88 on: December 07, 2021, 06:53:05 pm »
I think this is a regression since this did not appear with RC1:

- set a breakpoint somewhere in your code
- sun the program in Release mode
result: the breakpoint becomes invalid.

This is new but might be OK, since it is no debug run.
But now
- stop the program
result: the breakpoint stays invalid, also when you changed the build mode to "Debug"

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-73-g0bf8dc1256)
FPC 3.2.3 x86_64-win64-win32/win64

I think the breakpoint should become valid again when the program is not executed like it was before.
« Last Edit: December 07, 2021, 07:02:03 pm by Muso »

Muso

  • Sr. Member
  • ****
  • Posts: 356
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #89 on: December 07, 2021, 07:01:28 pm »
For example in my IDE, I hav many "gdb" debuggers defined. For testing diff gdb versions.
If FpDebug will have more options, maybe some people want several configs.

So just "FpDebug" is not possible. Which of the many configs would that be?

I will create the bug report as you requested.

Concerning the feature, this is my use case:

- PC A has 2 debuggers defined, FPDebug,
 and GDB
- PC B has no explicit debuggers defined (thus it has by default only FPdebug)

In the project options, I set on PC A to use the FPDebug. Fine, but now I open the project on PC B. There is no explicit debugger and I get a warning about the missing debugger despite the desired FPDebug is available.

So for example in my case several persons work on a project on different PCs. The idea is that there is a debugger defined for the project so that all programmers use this. Therefore it is of importance if the debugger is GDB or FPDebug. As the feature is currently, I cannot achieve this.
But OK, this is maybe a wish for the future.

 

TinyPortal © 2005-2018