Local Vars often inspect with an error message

[SandyG]

When debugging code and trying to inspect local variables I end up often with this message

'XXX = <Error: Failed to read data from register>'

Where XXX is the name of a local variable. I assume that it's a variable that is getting put into a register but should not be a reason to not be able to inspect the value. Typically the variable type is a 'Single' floating point, where Integer types always seem to work fine.

Any tricks to make the debugger see these floating point values correctly?
I currently have to create a string variable, and convert the float to a string, then can debug inspect the string. Pain.

Running Windows 11,
Lazarus 3.0 (rev lazarus_3_0) FPC 3.2.2 x86_64-win64-win32/win64

I have tried both -O and -O1 optimizations and makes no difference, as well as messing with the Dwarf type, both 2 and 3. But doesn't seem to matter.

Am I missing a setting?

Thanks

Sandy

[Martin_fr]

An example (such as that I can compile and test on my Machine) would be good.

I assume you are using "FpDebug"? => Tools > Options > Debugger Backend


One Idea: You say you tried -O- and -O1 => Are those variables/procedures in the project code, or are you calling a function in a package (e.g. LCL)? If it is a package, then make sure to replicate that setting for the package (as packages have their own settings / Can be forced by "Additions and Overrides").

You may try the GDB backend. Just to confirm if it makes a change.

[SandyG]

Yes, shows up as FpDebug for the backend.

the -O and -O1 are the optimization levels on the project options for 'Optimization Levels' and it doesn't seem to matter.

The code that is being debugged is a component, but it gets recompiled each time. I will double check that the component library settings are OK too, ie, optimization level and related to see if that makes any difference. That could be the area where something is not set for debugging as I'm currently looking at my project and debugging the component as it's being used in the project (hope that makes sense). So may be something related to compile/debug options in the BGRAComponent build that is possibly not set up for debugging.

If I can't find anything odd I'll try a simple program to see if I can duplicate it.

Thanks for the quick reply!

Sandy

[Martin_fr]

Other things to look out for... They should all work, but may hold clues:

- When the error happen, is the top stack selected?
  I.e. in the stack-window the green arrow (or yellow arrow in breakpoint) in the left-most column is at stack 0 (zero)
  For this NOT to be the case, would usually mean that you changed it.
- Is the correct stack selected (an exception may internally stop at fpc_raiseexception, but the debugger shows your code)
  Though if other locals work then that should be the case

Also: Are you in a "nested" procedure? (A procedure declared inside another procedure)?
Or are you inside a "finally" block?


At the time of it happening, can you open the "Register window" (menu View > Debug Windows) and see which registers are there? (looking for RSP and RPB or on 32 bits ESP and EPB)

Can you open the asm window and copy the asm (plus/minus 10 lines) for the code where you are paused (assuming that this code actually accesses the local variable)

As I write this I just realize:

Local vars that are not accessed in code may not be present in the exe. But since you try to get a value of it, that seems unlikely to be the cause.

And variables marked as "threadvar" may not be accessible at all, but I would probably expect a different error.

[SandyG]

Martin -

The debugging issue does not happen as a result of an error, I typically set a breakpoint on a line of code and when it hits, I look around at some variables. No thread vars, nothing like that. No nested procedures either.

Example code below where I see the issue, note that in this case the variables can be computed and optimized away I'm guessing, but this still happens in other places of the code. I will try to work up a more concrete and stand alone example to see if I can make something you can try as well.

Code: Pascal  [Select][+][-]

1. procedure TDTCustomThemedGauge.DrawMarker;
2. var
3.   Origin: TDTOrigin;
4.   mask: TBGRABitmap;
5.   x1, y1, x2, y2: integer; //These can be looked at when hovering during a breakpoint
6.   j, value : single;           // Can't look at (error display when hovering) or evaluate these in the debugger inspector
7.  
8. begin
9.  
10.   // skip drawing if nothing changed or not drawn
11.  
12.   if (not FMarkerSettings.Dirty) then
13.     Exit;
14.  
15.   FMarkerSettings.Dirty := False;
16.  
17.     // Now, if not enabled we can leave if flag reset!
18.  
19.   if not FMarkerSettings.Enabled then
20.     exit;
21.  
22.   Origin := Initializebitmap(FMarkerBitmap, Width, Height);
23.  
24.   j := (180 - 270) / 2;
25.  
26.   if MarkerSettings.Style = msCenter then
27.     begin
28.         // draw a downward pointing triangle and border
29.  
30.         if FRangeLEDSettings.Style = lsFlat then
31.           begin
32.  
33.         value := 25;  // hack test
34.  
35.       /// Draw center line of triangle for starters
36.       // 25 test angle in degrees
37.  
38.         x1 := Origin.CenterPoint.x - Round(FMarkerSettings.Radius * cos((j + value * 270 / FMaxValue) * Pi / 180));
39.         y1 := Origin.CenterPoint.y - Round(FMarkerSettings.Radius * sin((j + value * 270 / FMaxValue) * Pi / 180));
40.  
41.       // Calculate draw to point top
42.  
43.         x2 := Origin.CenterPoint.x - Round((FMarkerSettings.Radius - FMarkerSettings.Height) * cos((j + value * 270 / FMaxValue) * Pi / 180));
44.         y2 := Origin.CenterPoint.y - Round((FMarkerSettings.Radius - FMarkerSettings.Height) * sin((j + value * 270 / FMaxValue) * Pi / 180));
45.  
46.         FMarkerBitmap.LineCap := pecSquare;
47.         FMarkerBitmap.DrawLineAntialias(x1, y1, x2, y2, FMarkerSettings.Color, FMarkerSettings.Width);
48.       end;
49.     end;
50. end;
51.  

[Martin_fr]

Couple of other things that can be done.

1) Run the IDE

Code: Text  [Select][+][-]

1. lazarus.exe --debug-log=c:\path\to\log.txt  --debug-enable=
2. DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS,DBG_VERBOSE_BRKPOINT,DBG_STATE,DBG_EVENTS,DBG_COMMAND_ECHO,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINTS,FPDBG_COMMANDS,FPDBG_THREADS,FPDBG_QUEUE

Slight chance the logfile will have something.

Additional an exe (or objdump) may help. Either would allow me to see the actual debug info for the local var, and from that check if I can figure something out.
With that I would need
- name of the unit and function
- name of the local var

A compiled exe can be send to my private email.
Or you can run objdump on it yourself (and zip the result)

Code: Text  [Select][+][-]

1. /objdump.exe --dwarf=info project1.exe > dwarf.txt

EDIT

The data will be huge, but you can also check yourself

Code: Text  [Select][+][-]

1.  <2><13e18f>: Abbrev Number: 7 (DW_TAG_subprogram)
2.     <13e190>   DW_AT_name        : FormCreate
3.  
4. ...
5.  
6.  <3><13e1e0>: Abbrev Number: 10 (DW_TAG_variable)
7.     <13e1e1>   DW_AT_name        : value
8.     <13e1e7>   DW_AT_location    : 2 byte block: 90 19  (DW_OP_regx: 25 (xmm8))
9.     <13e1ea>   DW_AT_type        : <0x13eb91>
10.  

Here the variable is called "value"

And if location contains DW_OP_regx then that is not currently supported (not sure if gdb does / gdb 12 seems to do it)

Usually I would not expect that with -O- or -O1

(unless you enable -ooregvar or have a directive to enable it in the code)

[Martin_fr]

Btw, I can get the same error by compiling with -O2
And integer vars are readable, though the correctness of the value is (probably) pure luck in that case.


With O2 the value is indeed stored in a register. And FpDebug only reads from the integer registers.
But that is not helpful, as fpc does not  (or did not, last time I checked) write enough debug info to deal with a register being used for different vars at different lines of code.

[SandyG]

I built a simple program that had a few integers, singles, and some code that adds and displays the results in the caption of a Label.

Tried a bunch of different ways to make it NOT work, and it always inspected the single variables just fine.

I also looked at the settings for the component library and it had a setting of optimization of NONE, but I need to make sure that it's really the case. The code that is being debugged is my changes to a component in the package and I know that is a fresh compile, but maybe something else is going on that is compiling with -O2 as a compiler setting.

I have not had a chance to logfile with the command line as you gave, will try to get a chance to do it this weekend.

Sandy