Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Progress made with Lazarus/Free Pascal + Native Debug #118

Open
carlca opened this issue Jul 26, 2017 · 30 comments
Open

Progress made with Lazarus/Free Pascal + Native Debug #118

carlca opened this issue Jul 26, 2017 · 30 comments

Comments

@carlca
Copy link

carlca commented Jul 26, 2017

lldb --version: lldb-370.0.42 -

Hello, further to my post a couple of months ago #106 , I have tried again with Native Pascal, and have managed to get further this time.

I'm not seeing the flurry of error messages in the debug console so that's good. I am, however, still having problems accessing variables. As you can see from the screenshot below, I have, for example, a variable called Code. This is an instance of the TCodeBuffer class. The default entry in the variable list doesn't work because Lazarus/FPC does a dereferencing trick to make the true value of *Code appear as Code in the code. If however, I add a watch with the variable specified as *CODE then I get to see the variables class name displayed. It also successfully displays simple class members, such as strings, numbers and booleans.

The second screen shot shows the Xcode application working with LLDB to debug the same Lazarus/FPC application. My logic is that if Xcode can do it, then it must be theoretically possible for Native Debug to do the same thing. I'm not suggesting it's easy, just theoretically possible!

screen shot 2017-07-26 at 17 18 37

screen shot 2017-07-26 at 17 26 02

Why not just use Xcode, you may ask. Well, VSCode is a much more pleasant application to use compare to Xcode, IMO.

I know you said you don't have any FPC/Lazarus/Pascal experience but hopefully, I've been able to supply a little more useful information this time.

To recap then, can you help me uncover more of LLDB's hidden variable information?

Thanks in advance,
Carl
@WebFreak001
Copy link
Owner

can you send me some source that is as minimal as possible to replicate the problem?

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@WebFreak001
Copy link
Owner

Could you provide me with build instructions?

I tried lazbuild webfreak.lpi but it errored:

Error: (lazarus) invalid Lazarus directory "": directory lcl not found
Error: (lazarus) Building failed: webfreak.lpi

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@WebFreak001
Copy link
Owner

both, are you sure the lpi file is correct? It references <PackageName Value="LCL"/> and stuff

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@WebFreak001
Copy link
Owner

what's your build procedure, I haven't setup anything yet, I just installed lazarus and fpc from the arch repositories

@Wosi
Copy link
Contributor

Wosi commented Jul 26, 2017

Did you start Lazarus so far? AFAIK it's doing some configuration on first start up.

@WebFreak001
Copy link
Owner

uhh I didn't install any gui with it yet, but I can get the gui for lazarus and try that

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@WebFreak001
Copy link
Owner

ok I managed to build it and I can reproduce crashes now when trying to expand the variable, I will try to find out the reason.

@WebFreak001
Copy link
Owner

This seems like an lldb issue to me

(lldb) breakpoint set -f uwebfreak.pas -l 51
Breakpoint 1: where = webfreak`RUNWEBFREAK + 180 at uwebfreak.pas:51, address = 0x00000000004724e4
(lldb) run
Process 1755 launched: './webfreak' (x86_64)
Process 1755 stopped
* thread #1, name = 'webfreak', stop reason = breakpoint 1.1
    frame #0: webfreak`RUNWEBFREAK(this=0x00007ffff7fa3100) at uwebfreak.pas:51
   48  	  List := TStringList.Create;
   49  	  try
   50  	    for I := 0 to 99 do
-> 51  	      List.Add(IntToStr(I));
   52  	    writeLn(List.Text);
   53  	  finally
   54  	    List.Free;
(lldb) bt
* thread #1, name = 'webfreak', stop reason = breakpoint 1.1
  * frame #0: webfreak`RUNWEBFREAK(this=0x00007ffff7fa3100) at uwebfreak.pas:51
    frame #1: webfreak`RUN(this=0x00007ffff7fa3100) at uwebfreak.pas:30
    frame #2: webfreak`main at webfreak.lpr:15
    frame #3: 0x000000000040018c webfreak`_start + 64
(lldb) print LIST
error: need to add support for DW_TAG_base_type 'FormalDef' encoded with DW_ATE = 0x7, bit_size = 0
error: need to add support for DW_TAG_base_type 'EXTENDED' encoded with DW_ATE = 0x4, bit_size = 80
Stack dump:
0.	HandleCommand(command = "print LIST")
1.	<eof> parser at end of file
2.	Parse:41:16: Generating code for declaration 'TWEBFREAK::$__lldb_expr'
fish: “lldb ./webfreak” terminated by signal SIGSEGV (Address boundary error)

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@WebFreak001
Copy link
Owner

well I used lldb without any extension or code in between there, and if I can't get the command line debugger to work I won't be able to fix an extension using it. I am using lldb version 4.0.1 which should be newer than your version there.

@carlca
Copy link
Author

carlca commented Jul 26, 2017 via email

@WebFreak001
Copy link
Owner

yaourt -S lldb, it's an archlinux package https://www.archlinux.org/packages/extra/x86_64/lldb/

@carlca
Copy link
Author

carlca commented Jul 26, 2017

I think I have misunderstood something. I didn't realise that you were doing everything on ArchLinux. That would explain why you couldn't run Xcode! I hope you don't regard this as "the typical arrogance of the Apple Mac user" !!

@carlca
Copy link
Author

carlca commented Jul 26, 2017 •
edited

When you set the breakpoint in LLDB, did you try doing `print *LIST' ? Like I said, Lazarus and Delphi do some dereferencing tricks to make variables which should appear as *[varname] actually appear as [varname]. LLDB doesn't understand this, so you have to speak in real "pointer" terms to it.

@carlca
Copy link
Author

carlca commented Jul 27, 2017

Hi Jan, if you have a moment, grab the latest version of the sample app at https://dropfile.to/cYpBezD access code Evzwk2x. Stick a break point in LLDB at line 69, then do 'p *OBJ.LIST`. You should see the contents of the List object which is a child property of the Obj object. In other words, LLDB does allow the display of child properties. Interestingly, I've just tried this via the Add Watch facility in VSCode and it seems to work here. It didn't seem to work in the actual app I'm working on, though.

So what would be good is if the list of Variables was able to detect which of the variables was a class reference, and to ask LLDB for the * value, so that we don't have to add the values manually as watches.

I hope that all makes sense.

Cheers,
Carl

@carlca
Copy link
Author

carlca commented Jul 27, 2017

Jan, something bad has happened! I no longer am able to stop at breakpoints at all. I've tried uninstalling and reinstalling Native Debug, but I cannot get breakpoints to work at all. This rather blows my progress out of the water. Do you have any idea what the problem might be?

@WebFreak001
Copy link
Owner

have you tried using a different compiler or different arguments to emit gdb compatible debug symbols?

@carlca
Copy link
Author

carlca commented Jul 27, 2017

No, I haven't done anything differently, as far as I know. It just stopped working suddenly.

@carlca
Copy link
Author

carlca commented Jul 27, 2017

It hasn't worked since last night. Something has happened overnight to cause me to lose the use of breakpoints.

@carlca
Copy link
Author

carlca commented Jul 27, 2017

It's OK my LLDB is working again. Not sure what the problem was, to be honest.

@carlca
Copy link
Author

carlca commented Jul 27, 2017

Any thoughts about the P *OBJ.LIST thing I mentioned earlier?

@genericptr
Copy link

I was trying to get LLDB to work with Free Pascal and found this thread. On my system (10.13 lldb-900.0.45) the "p" command is broken and crashing but "fr v" works and displays members variables of classes.

Look at this example and notice how "p" crashes at the end but I get member variables using fr v. Not sure if this is relevant or helps.

(lldb) fr v MODEL
(TMODEL) MODEL = 0xbffff95c
(lldb) fr v *MODEL
(TMODEL) *MODEL = {
  TOBJECT = {
    REGISTEREDMETHODS = 0x000007c3
    MANAGEDOBJECTS = 0x0064bf00
    AUTORELEASECOUNT = 0
    RETAINCOUNT = 0
    DIDINITIALIZE = true
    INITIALIZEDFROMCOPYING = true
    COPYPARAMETERS = 0xb9938c00
  }
  MESH = (VERTEXATTRIBS = 0x3e45a200, VERTEXSIZE = -1476722686, V = 0x00000000, IND = 0xe04e6620)
  MATERIAL = {
    SHINEDAMPER = 0.961168169
    REFLECTIVITY = -5.949044E+19
    TEXTURES = (M_DATA = 0x3f760f1e, M_ACTUALSIZE = 19562528, M_GROWSIZE = -1073743432, DATA = 0x3f760f1e)
    COLOR = (X = 0.0000000000000000000000000000000000000000971225952, Y = 0.000000000000000000000000000000000000000100446475, Z = 0.00000000000000000000000000000000000000000112103877, R = 0.0000000000000000000000000000000000000000971225952, G = 0.000000000000000000000000000000000000000100446475, B = 0.00000000000000000000000000000000000000000112103877)
    ID = -1073743368
  }
  SHADER = 0x0001190c
  ID = 1599792
  VERTEXBUFFERID = 1599792
  INDEXARRAYBUFFERID = 3221223896
  VAO = 213793
}
(lldb) fr v *MODEL->SHADER
(TSHADER) *MODEL->SHADER = {
  TOBJECT = {
    REGISTEREDMETHODS = 0x8b042474
    MANAGEDOBJECTS = 0x8d08247c
    AUTORELEASECOUNT = 9316
    RETAINCOUNT = 49932
    DIDINITIALIZE = true
    INITIALIZEDFROMCOPYING = true
    COPYPARAMETERS = 0xf424648d
  }
  PROGRAMID = 2365623040
  VERTEXSHADERID = 3272352868
  FRAGMENTSHADERID = 4096025741
  UNIFORMS = 0x89241c89
}
(lldb) p *MODEL
Illegal instruction: 4

@pakLebah pakLebah mentioned this issue May 27, 2018
Open
8 tasks
@GitMensch
Copy link
Collaborator

@carlca @genericptr Any update on this? Could you possibly retry that, maybe with an updated LLDB and also with GDB?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@carlca @WebFreak001 @Wosi @GitMensch @genericptr