Trunk fpdebug on mac

[Okoba]

Hello,
I just installed both the stable (Lazarus 2.2.0 (rev Unknown) FPC 3.2.2 x86_64-darwin-cocoa) version and Trunk (Lazarus 2.3.0 (rev main-2_3-1003-g8d60667e33) FPC 3.3.1 x86_64-darwin-cocoa) on an M1 machine, and config both on lldb debugger with fpdebug and set the path to "/usr/bin/lldb".

Ran a simple code like:

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

1. program Project1;
2.  
3. var
4.   A, B: Integer;
5. begin
6.   A:=1;
7.   B:=A;
8. end.
9.        

The stable version can show the values as a hint, but Trunk shows "Internal error: Failed to read the data from memory".

Is there something I should config on Trunk or is this a bug?

[Martin_fr]

It sounds like a bug. But....

A few tests needed.

You use different fpc versions for each of the IDE. So it could be either:
- the debugger has a regression
- the newer fpc compiles something that causes the problem (even when debugged inside the 2.2.0 debugger

     Step 1   

on an M1 machine

And your IDE is compiled as
- native M1 ?
- Intel (running as emulation) ?

And the project you debug is compiled as
- native M1 ?
- Intel (running as emulation) ?

1) Are those answers/settings the same for both installations?

2) There was code added, to support debugging native M1 apps.
If either of the 2 answers is "Intel" => then maybe the issue is that the debugger wrongly things it's M1.
In that case it would try to find M1 registers => and if the app is intel, then that would be an issue.

** Check the "register window" if the registers match the project.

** Run your IDE from a console (see the link for creating a log below). And specify
   --debug-enable=DBG_ERROR,DBG_VERBOSE
  When starting the debugger look for a line like:
    Target 64 bit:...
    Target ARM/M1:...

Does it match your project settings?

     Step 2   

Ensure you compile the project (which you want to debug) with
- -O- (no optimization, not even O1)
- the same dwarf setting. (dwarf-2-with-sets or dwarf-3)
- Try with and without external debug info.

Please also add A and B as watches in the watches-window, and check the results in the watches window.

Depending on the results, if those works you can then find out which changes will break it.

Note: There have been other cases in the past, with different compiler versions, where using -O1 caused some watches in some context to return wrong values.

     Step 3   

Using the 2.3 IDE (build with FPC 3.3.1):
- change the compiler to fpc 3.2.2
- compile the project with 3.2.2 and debug

Optional, in the 2.2.0 IDE compile the project with fpc 3.3.1

     Step 4   

Which settings did you use to build your IDE?
Did you build the IDE with -O- or -O1 or -O2 or above?
Did you build both IDE with the same settings?

Did you have an earlier Lazarus 2.3? If yes, did the earlier 2.3 work better? Do you remember the revision, or date?

Depending on the outcome, there may be more questions later.....

You can create a log:
https://forum.lazarus.freepascal.org/index.php/topic,42869.0.html

There is currently some work on the debugger in progress. Given the error: "unable to read mem" it is unlikely to be the related.

[Okoba]

Hello Martin,

- These are completely fresh install on a fresh machine. I delete everything I could find before install and before that I had problematic versions with problems with debugger and crashing ...
 (More).

Step 1:
- Stable version is installed from source forge latest files. Trunk version installed with fpcupdelux. Maybe this is an issue? Although I installed the LazDebuggerFpLLdb and set proper debugger setting
- Both X64 versions and I think running as emulation (I do not know how to verify!) and Trunk version FPC path is ".../fpc/bin/x86_64-darwin/fpc.sh" So I am pretty sure it is running X64. I included exact version detail in the first post.
- Projects are running with default target OS, CPU family and processor, so I think running as emulation (again, I do not know how to verify!)
- I could not find the "target 64 bit ..." line that you mentioned, but I attached the logs, so please let me know if there is any and I missing it or not.

Step 2:
- Tested with O0, and added watches, no changes and watches shows the error too.

Step 3:
- Changing the Lazarus 2.3 from FPC 3.3.1 to FPC 3.2 fixed the problem, debugger worked properly, including the watches in O0 and O1.
- Changing the Lazarus 2.2 from FPC 3.2 to FPC 3.3.1 corrupted the debugging.

Step 4:
- I did not build the Trunk version by myself, it was made by fpcupdelux. The setting seems set on "-g -gl -O1" , I removed it (as the Stable version seems has no options) and rebuild, no changes and still error.

[Martin_fr]

Ok, so it looks like fpc trunk changed something. From the log it looks like its relocation related. (I.e. fpdebug now sees it without relocation, but it may be hidden somewhere....)

Have to check with the fpc team....

[Martin_fr]

The only answer I got sofar https://lists.freepascal.org/pipermail/fpc-devel/2022-March/044559.html

If you debug this directly in lldb (outside the IDE), does lldb print the correct value for the variables?

- If not, then this is most likely an issue in fpc itself.
- if lldb can print the values, then fpdebug likely needs to be adapted.

[Okoba]

Can you tell me how can I test directly in lldb?

[Martin_fr]

I don't recall the command line.

But you can install LazDebuggerLldb package (the one without "fp" in the name).

Then choose "LLDB Debugger (Alpha)" as debugger. 
It does only support the most basics. But you can add your test vars as watch. (not sure if hints will work).

[Okoba]

Tested with the "LLDB Debugger (Alpha)" and the same Trunk version as before, and same project.
Hint and watches work.

[Martin_fr]

Ok, so it's likely an intentional change in fpc (or the linker, but I would guess that both your fpc use the same linker / the linker being part of the apple tools)

It could be an argument given to the linker. I.e. controlling if the resulting exe is relocatable.

I don't have a list of the -X... flags, and what the Mac linker can be given. It's possible that there is a setting to make it work.

Otherwise, it depends if the (probably "per section") relocation info can be queried from lldb. I don't know yet. => Please open a bug in the Lazarus bug tracker.
(It might be some time, before I get to it....)

Btw, if you need to use fpc trunk, and then likely get stuck with the  "LLDB Debugger (Alpha)" you may find (or maybe not) that more complex watches wont work.
In this case there are some settings to play with.

1) dwarf 2,3 or 4 => though most likely 3 and 4 will have the same results.
Dwarf 4 is can be added as custom option: -gw4

2) -godwarfcpp
Afaik this can be added to any of the dwarf levels. Or maybe just some.  It may help lldb to get better results.

You have to test which combination works best for you.

[Okoba]

Thank you for the details.
Added the issue.