debug | evaluate does not know about LCL

[Martin_fr]

Different topic: You said you still had trouble with the debugger, after that fix (the fix as it currently exists).

[lazer]

I'm just testing my assert() mod on the two procs affected by the patch, without the reordering.

It's fairly same on a simple project but still no blue dots on the real project, apart from in the lpr file.

[Martin_fr]

see what
  objdump --dwarf=decodedline project
shows?

You can also check if
  objdump --dwarf=info project
shows anything for that unit (searching for a compilation unit with that name)

[lazer]

while redirecting output to a file, I'm still getting this directly to console.

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

1. objdump: Warning: Bogus end-of-siblings marker detected at offset 39aa7 in .debug_info section
2. objdump: Warning: Bogus end-of-siblings marker detected at offset 39c1b in .debug_info section
3. objdump: Warning: Bogus end-of-siblings marker detected at offset 39c84 in .debug_info section
4. objdump: Warning: Further warnings about bogus end-of-sibling markers suppressed
5.  

Also in the obj file a few cases like this:

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

1.  <1><89377d>: Abbrev Number: 43 (DW_TAG_array_type)
2.     <89377e>   DW_AT_byte_size   : 40
3.     <89377f>   DW_AT_byte_stride : 40
4.     <893780>   DW_AT_type        : <0x89320d>
5.  <2><893784>: Abbrev Number: 44 (DW_TAG_subrange_type)
6.     <893785>   DW_AT_lower_bound : 0
7.     <893786>   DW_AT_upper_bound : 0
8.  

Is that legit ?

o/w I see my varaibles with appropriate initial values.

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

1.  
2. CU: bat1.pas:
3. File name                            Line number    Starting address    View    Stmt
4. bat1.pas                                     629            0x466520               x
5. bat1.pas                                     629            0x46655c               x
6. bat1.pas                                     630            0x466583               x
7. bat1.pas                                     631            0x466598               x
8. bat1.pas                                       0            0x4665a3
9. bat1.pas                                     632            0x4665a8               x
10. bat1.pas                                       0            0x4665b1
11. bat1.pas                                     632            0x4665c5               x
12. bat1.pas                                       -            0x4665ce
13.  

I guess the x column corresponds to blue dots but I don't get them in IDE.

[Martin_fr]

I have to see if I can find something about those "bogus" markers.
If you search for the offset in the output (I think in the <>)  then what data is at those locations.

The array looks like
   type TFoo = array [0..0] of TData
where sizeOf(TData) = 40


Yes the "x" (or any line number >= 1) should be the blue dots.
The 0 lines are known. I don't recall the exact background.

So "bat1.pas" should have blue dots.
But what about the unit where you did not see blue dots?

- Is it in the decodedlines?

- Does the unit name appear in the "info" section (i.e. are variables for those units described)?

- Are you sure the code is in the exe?
  This may sound strange, but if you have a procedure that  is never called (nor otherwise referenced), then it may be left out.

[lazer]

OK. Yes, the program runs , I get the main window and it closes without error.

So "bat1.pas" should have blue dots.
But what about the unit where you did not see blue dots?

That file included the main window and the previously meantioned Object which I now declare as a class

 

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

1. type
2.  
3.   Ppack=^Tpack;
4.   Tpack= class
5.     private
6.  

This project only has one form in one pas file. ( I removed the about dlg to simplify).

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

1.   function fileexpand(fn:string; s:AnsiString):Pchar;
2.   begin  // line 629 of bat1.pas
3.     fn:=s;
4.     result:= @fn;
5.   end;
6.  

That code is not called and is a global function outside the Form class, so not much optimisation cutting out code.

I have to see if I can find something about those "bogus" markers.
If you search for the offset in the output (I think in the <>)  then what data is at those locations.

The array looks like
   type TFoo = array [0..0] of TData
where sizeOf(TData) = 40

the first bogus end-of-siblings marker, the last looks similar:

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

1.  <1><39a91>: Abbrev Number: 68 (DW_TAG_subrange_type)
2.     <39a92>   DW_AT_lower_bound : 0
3.     <39a93>   DW_AT_upper_bound : 14 byte block: 97 6 12 28 5 0 9 ff 2f 3 0 38 1c 6   (DW_OP_push_object_address; DW_OP_deref; DW_OP_dup; DW_OP_bra: 5;>
4.     <39aa2>   DW_AT_type        : <0x252196>
5.  <1><39aa6>: Abbrev Number: 0
6.  <0><39aa7>: Abbrev Number: 0
7.  <-1><39aa8>: Abbrev Number: 15 (DW_TAG_reference_type)
8.     <39aa9>   DW_AT_type        : <0x39a63>
9.  <-1><39aad>: Abbrev Number: 13 (DW_TAG_typedef)
10.     <39aae>   DW_AT_name        : TVarRec
11.     <39ab6>   DW_AT_type        : <0x39aba>
12.  
13.  

the second one:
 

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

1. <0><39c0c>: Abbrev Number: 30 (DW_TAG_member)
2.     <39c0d>   DW_AT_name        : VQWord
3.     <39c14>   DW_AT_data_member_location: 2 byte block: 23 8  (DW_OP_plus_uconst: 8)
4.     <39c17>   DW_AT_type        : <0x3ccf6>
5.  <0><39c1b>: Abbrev Number: 0
6.  <-1><39c1c>: Abbrev Number: 15 (DW_TAG_reference_type)
7.     <39c1d>   DW_AT_type        : <0x39aad>
8.  <-1><39c21>: Abbrev Number: 13 (DW_TAG_typedef)
9.     <39c22>   DW_AT_name        : PChar
10.     <39c28>   DW_AT_type        : <0x39c2c>
11.  <-1><39c2c>: Abbrev Number: 19 (DW_TAG_pointer_type)
12.  

[Martin_fr]

With all the testing that you have done, are you sure your compiler has the full fix?

Especially line 3964 changed from "14" to "15" ?

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

1.           DW_AT_upper_bound,DW_FORM_block1,15

Because your objdump looks like it still puts a 14 in there.



You may want to consider using git. That will make updating easier for you.

Code: Bash  [Select][+][-]

1. # clone into directory fpc_git
2. git clone https://gitlab.com/freepascal.org/fpc/source.git ./fpc_git
3.  
4. # update (if you have no modifications
5. git pull
6.  
7. # export the source to the build directory
8. # fpc_source_for_build is where you will run make / and what you will give the IDE as fpc source dir
9. # this may not copy local modifications / you can modify the export
10.  
11. # if needed, either
12. rm -rf /path/to/fpc_source_for_build/*
13. mkdir /path/to/fpc_source_for_build
14.  
15. git  --git-dir=/path/to/fpc_git/.git  --work-tree=/path/to/fpc_source_for_build  restore  .
16.  
17. # see modifications you made in your fpc_source_for_build
18. git  --git-dir=/path/to/fpc_git/.git  --work-tree=/path/to/fpc_source_for_build  diff
19.  
20. # temporary save your changes from fpc_source_for_build  
21. git  --git-dir=/path/to/fpc_git/.git  --work-tree=/path/to/fpc_source_for_build  stash push
22. # then overwrite fpc_source_for_build  with an update
23. # and restore the changes to fpc_source_for_build
24. git  --git-dir=/path/to/fpc_git/.git  --work-tree=/path/to/fpc_source_for_build  stash pop
25.  
26.  

Or make a local branch for your changes, if you go into playing a lot with the fpc sources

Mind you, the above git syntax is way more complex that any git you normally ever find.
This is because a 2nd directory is created for the fpc build process. And we use (abuse) git to copy the files.

You can just copy your entire git dir, and then delete the .git
Then changed files in your git dir will be copied with the changes (in the above you would need to commit them to copy the changes / or add them to the index and use a diff syntax)


So are the blue dots solved then?

[lazer]

Sorry I should have rerun objdump again, it may have been old.

I already moved to using git.  To be sure, I removed everything in sight. fpc libs configs, source trees, the lot.

I pulled a clean tree for fpc and laz.
Built fpc with distro 3.2.2
This time I installed to /usr/local/lib which is probably where this should have gone to start with.
I reset symlink to 3.1.1 and build lazarus.

Now it looks a bit cleaner: no sibling probs and I have blue dots everywhere I'd expect them. ( debugging set to dwarf3 )

However, the good news stops there. I can step into lpr file but breakpoints and run to cursor inside the pas file have no effect , it's just like a normal Run.

At least it looks a bit more sane.

The trivial test prog steps and debugs as expected.

[Martin_fr]

However, the good news stops there. I can step into lpr file but breakpoints and run to cursor inside the pas file have no effect , it's just like a normal Run.

Yet that pas file (in which breakpoint fail) has blue dots?

And the breakpoint is on a line that has a blue dot? (well you will not see the blue dot, if the breakpoint is set, but if you un-set the breakpoint, then there should be a blue dot)?

If breakpoints don't work "Run to cursor" will not either, because it just internally sets the breakpoint. (Though "run to cursor" will look for a blue-dot below, if the line itself does not have one / breakpoints only ever look at the exact line).


- Before you start the debugger breakpoints should be a "red ball" with a question mark on it.
- When the debugger runs, they should be a "red ball" with a "check-mark" on it.

If the have any other color or symbol then please report.

[lazer]

All is as you describe.