Debugger fails to read data from register

[jwdietrich]

When debugging on macOS, it is impossible to display the contents of certain numeric variables. Strings and real numbers as parts of a record can be shown, but for plain real numbers, the debugger returns "Failed to read data from register".

Is this a bug, or have I omitted a necessary setting? The same problem occurs, regardless of whether I use Dwarf 2 with sets or Dwarf 3.

The problem occurs in Lazarus 4.0 with Free Pascal 3.2.2 on macOS Ventura 13.7.6.

[Martin_fr]

Did you compile with or without optimization?

At the very least with O2 up this will happen. With O1 I have not seen it myself. But I wouldn't know for sure on Mac, since I don't have Mac.

If it happens with -O- then it may need more investigation.
The need to work with lldb makes the debugger more complex on Mac.

Is it the top stack frame, or did you select a calling frame?


Background:

The error can have different reasons.

Either the value is (due to optimization) stored in a register. Then it may be not implemented to read that. At least not with the combination with lldb. (FpDebug alone can do that, at least as far as I was able to test - but also FPC does not always write the correct register so in that case value will be wrong / it works on Linux if compiling with the llvm backend).

Or, the value is not in a register. But a local var is on the stack, so the stack register (actually base register) must be found *and* read. That should work, if there is no optimization in play.

[Martin_fr]

Also, I just see the parameter is "extended"

That could also be the cause. I am not sure if that got ever tested on Mac.
Also extended underwent changes since then, and as I don't have a Mac, it then certainly did not get tested.

At least on Windows extended only exists on 32bit. So to cross debug that from 64bit, it needs softfloat support. I don't know if that works on Mac.

Though if that was the case, then the error message was off.


And one other note.
Though according to your image, not the case.

If paused on the "begin" line of the procedure, then all locals are wrong. On the begin line the code has not yet set up the storage for any locals / including parameters.

However you are on the next line.

[jwdietrich]

Thanks for your advice. It was optimisation. Switching it off or using -O1 reenables the display of real and extended numbers.

[Martin_fr]

Mind you that with optimization you may not just get errors, but randomly wrong results.

With -O1 it is likely going to be ok.
In the past (but IIRC/afaik that got fixed before 3.2.2) variables might simple have been outdated for the duration of 1 source line. Because when the optimizer reduced the amount of "write to mem / read back from mem" it did move boundaries of the lines.

But of course that can still happen.

With -O2 (and FPC) you will get wrong values. FPC may write debug info, that a value is a specific register (rather than in memory).
But FPC simple says "it is in that register" and that is wrong as it means for the duration of the whole procedure. Even though the register may be used for different vars during that procedure. And well, then the value becomes random. (Or can't be read, if e.g. the register can't be gotten - like with lldb).

If you compile with the llvm backend (be careful the FPDebug debugger has not been fully tested for that, but generally seems ok), then llvm will write correct scope for the registers. And at least on Linux some basic tests have been successful for FpDebug to read that correctly.
But there may still be cases....

GDB I have not tested.
Pure LLDB (without FpDebug / outside the IDE) will likely deal with llvm generate debug info.

Code generated by other compilers (including from other source languages) may or may not work... There are too many variations...