[SOLVED] How to debug the *.inc files of the FPC?
lazarus / 12-Debugger
----------------------------------------------------------------------
devEric69 · 2019-05-07 10:06
Hello,
I used this thread to successfully debug the LCL (Actnlist.pas, etc):
https://forum.lazarus.freepascal.org/index.php/topic,24319.msg146262.h
tml#msg146262
To summarize:
- I have copied the directories (lazarus)/lcl, (fpc)/packages,
(fpc)/rtl and (fpc)/utils that were installed by Fcpupdeluxe, into a
directory of my /home, ie in /home/Me/lcl, /home/Me/packages and
/home/Me/utils.
- I've renamed (lazarus)/lcl to (lazarus)/__lcl, (fpc)/packages to
(fpc)/__packages and (fpc)/utils to (fpc)/__utils.
- I've created 4 soft symlinks. A soft symlink named "(lazarus)/lcl"
pointing to /home/Me/lcl, a soft symlink named "(lazarus)/packages"
pointing to /home/Me/packages, a soft symlink named "(lazarus)/rtl"
pointing to /home/Me/rtl, and a soft symlink named "(lazarus)/utils"
pointing to /home/Me/utils.
- in /home/Me/Me/lcl, /home/Me/packages and /home/Me/Me/utils, I've
deleted all *.ppu and *.o files.
- in the IDE environment options (which apply to all projects), I've
added in "Debugger > Additional search path", the paths to the sources
I want to debug. For example, when I add /home/Me/Me/lcl, I can debug
the ActnList.pas file found there. I'm happy .
My problem occurs as soon as I want to debug a *.inc file (which
belongs to fcp anectotically). I would like to debug TStringList. The
declaration of this class is in the file
/home/Me/rtl/objpas/classes/classeh.inc, and its implementation is in
the file /home/Me/rtl/objpas/classes/stringl.inc. So, I added in
"Debugger > Additional search path", the path
/home/Me/rtl/objpas/classes.
However, when I put breakpoints in
/home/Me/rtl/objpas/classes/stringl.inc (in methods like
TStringList.InsertItem, or TStringList.Add), no blue dots appear, and
so, I can't debug this class .
Any idea, or clarification on the particularity of *.inc versus *.pas
in relation to the debugger, ... please?
----------------------------------------------------------------------
wp · 2019-05-07 10:38
In order to debug the LCL I normally go to "Project Options" >
"Compiler Options" > "Additions and overrides". Click on "Stored in
session of project" > "Add" > "Custom option", then click in the
appearing new "Custom" line and enter "-gw2" (without quotes). This
activates Dwarf2 debugger info for the project and all required
packages. When (after pressing "OK", of course) you compile the
project all units including LCL and third party units (except for RTL
and FCL units) will be recompiled with debugger info, and you can
debug them.
In order to debug RTL and FCL I add the file that I want to debug to
the project and confirm the prompt to add the related path to the
search path. After some iterations all required paths will be in the
search path, and the IDE will be able to compile also these units with
debug info.
I'd recommend to make a backup copy of fpc and project folder -
playing with fpc settings is always a bit risky.
I am not sure if -gw2 is still to best way, but Martin revealed to the
me once and it is still working fine.
----------------------------------------------------------------------
devEric69 · 2019-05-07 11:08
Hello,
Thank you for the answer.
I tested with your method, but it is still impossible for me to debug
the file stringl.inc (no blue dot; I've added the stringl.inc file in
my project with the menu "Project>Project inspector>Add files from
filesytem").
Have you ever managed to debug a *.inc file step by step (sorry for my
paranoid bias)?
----------------------------------------------------------------------
wp · 2019-05-07 11:12
I don't know whether adding the inc file to the project works.
stringl.inc belongs to TStringlist, and this is in classes.pas, isn't
it? Therefore, you should add classes (from the original fpc folder)
to the project.
----------------------------------------------------------------------
Martin_fr · 2019-05-07 11:39
You should not need "Debugger > Additional search path" (at least not
for LCL). The IDE already knows where those sources are. (That is, if
you do not move them around yourself).
I do not understand all your moving and symlinking.... Should not be
needed.
First in order to debug in any file, it needs debug info.
Files belonging to Lazarus (lcl, lazutils, other packages, that have
sources in Lazarus/components folder) can be recompiled with debug
info:
- open the package, open the options of the package, specify "generate
debug info"
- use "Additions and overrides" (project options / search wiki)
For fpc that is more complex.
The "copy a file" or "copy a folder" by wp, may sometimes work....
sometimes... If nothing else in fpc depends on the file.
Stringlist is in the RTL. So that requires the entire rtl to be
rebuild.
If you build your fpc, with fpcupdeluxe, there may be an option to
specify options for building fpc. You need
-gw -godwarfsets
Without fpcupdeluxe (or if that does not offer the option), you need
the full fpc sources, with makefiles, and you need to run make and
specify the options.
And you may want to change the settings for your project, and packages
from "debug info type" = "default" to "dwarf with sets".
----------------------------------------------------------------------
wp · 2019-05-07 11:57
I tried to follow my recipe with a simple project which creates a
stringlist. So far I had to add these unit folder to the search path
of the project:
C:\development\fpc\trunk\rtl\objpas;C:\development\fpc\trunk\rtl\win32
;C:\development\fpc\trunk\rtl\inc
and these inc files to the include path:
$(ProjOutDir);C:\development\fpc\trunk\rtl\inc;C:\development\fpc\trun
k\rtl\win;C:\development\fpc\trunk\rtl\win32;C:\development\fpc\trunk\
rtl\i386;C:\development\fpc\trunk\rtl\win\wininc
(Note that my fpc is in folder "c:\development\fpc\trunk", and I am on
Windows, obviously).
How I am stuck in unit InfoDwrf complaining about
"lnfodwrf.pp(1412,23) Error: Incompatible types: got "
" expected "". I've never seen
this... Martin, any idea how to proceed?
----------------------------------------------------------------------
Martin_fr · 2019-05-07 12:14
Quote from: wp on May 07, 2019, 01:57:48 pmHow I am stuck in unit
InfoDwrf complaining about "lnfodwrf.pp(1412,23) Error: Incompatible
types: got ""
expected "". I've never seen this...
Martin, any idea how to proceed?
{$H+} / {$H-} ?
But seriously the road you travel is slippery....
So you copied (and therefore recompile) all the files in rtl\objpas
(and a few others)
Now if anything in your project (including any package used by it)
uses anything of the rtl outside those folders that uses any code from
inside those folders, then you have a problem. Those still are pre-
compiled against the original ppu. So you get "checksum changed"
errors.
Yes you can identify all the needed files. And fix the folder
structure and what not.... It will be easier to recompile the entire
rtl using make (or probably possible with fpcupdeluxe)
----------------------------------------------------------------------
BrunoK · 2019-05-07 14:50
That's for wp, windows 10 / 32bit
First a call stack of what will be shown when compiled with a debug
version using bits and pieces of my FPC build process. (see
makefpc-306_w32.txt attachement)
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i #0
_INTERNALCREATE(0x196a3b8, 0) at ..\win\fstobjcr.pp:60#1
CREATE(0x1962420, 0x0, 0x196a3b8) at ..\objpas\classes\action.inc:91#2
CREATE(0x1962420, 0x1, 0x196a3b8) at include\customaction.inc:14#3
SETHINT(0x196a3b8, 0x65f4edc 'Displays the map') at
include\application.inc:1521#4 UPDA]"]>BlockedUSEHINT(0x196a3b8,
0x19774e8) at include\application.inc:478#5
UPDA]"]>BlockedUSECONTROL(0x196a3b8, 0x19774e8) at
include\application.inc:623#6 DOBEFOREMOUSEMESSAGE(0x196a3b8,
0x19774e8) at include\application.inc:2098#7
DOBEFOREMOUSEMESSAGE(0x19774e8) at include\control.inc:1435#8
WNDPROC(0x19774e8, {MSG = 512, WPARAM = 0, LPARAM = 1048807, RESULT =
0, WPARAMLO = 0, WPARAMHI = 0, WPARAMFILLER = {}, LPARAMLO = 231,
LPARAMHI = 16, LPARAMFILLER = {}, RESULTLO = 0, RESULTHI = 0,
RESULTFILLER = {}}) at include\wincontrol.inc:5431#9
DELIVERMESSAGE(0x19774e8, ) at lclmessageglue.pas:112#10
DOWINDOWPROC({WINDOW = 396222, MSG = 512, WPARAM = 0, LPARAM =
1048807, LMESSAGE = {MSG = 0, WPARAM = 0, LPARAM = 0, RESULT = 0,
WPARAMLO = 0, WPARAMHI = 0, WPARAMFILLER = {}, LPARAMLO = 0, LPARAMHI
= 0, LPARAMFILLER = {}, RESULTLO = 0, RESULTHI = 0, RESULTFILLER =
{}}, PLMSG = 0x162faf4, LWINCONTROL = 0x19774e8, WINPROCESS = false,
NOTIFYUSERINPUT = true, WINDOWINFO = 0x19e8f20, BACKUPBUFFER = {DC =
0, BITMAP = 0, BITMAPWIDTH = 0, BITMAPHEIGHT = 0}, WINDOWWIDTH = 0,
WINDOWHEIGHT = 0, PAINTMSG = {MSG = 0, DC = 0, PAINTSTRUCT = 0x0,
RESULT = 0}, RTLLAYOUT = false, ORGCHARCODE = 0, LMSCROLL = {MSG = 0,
SCROLLCODE = 0, SMALLPOS = 0, SCROLLBAR = 0, RESULT = 0, POS = 0},
LMKEY = {MSG = 0, CHARCODE = 0, UNUSED = 0, KEYDATA = 0, RESULT = 0},
LMCHAR = {MSG = 0, CHARCODE = 0, UNUSED = 0, KEYDATA = 0, RESULT = 0},
LMMOUSE = {MSG = 0, KEYS = 0, XPOS = 0, YPOS = 0, POS = {X = 0, Y =
0}, DUMMY = 0, RESULT = 0}, LMCONTEXTMENU = {MSG = 0, HWND = 0, XPOS =
0, YPOS = 0, POS = {X = 0, Y = 0}, DUMMY = 0, RESULT = 0}, LMMOUSEMOVE
= {MSG = 512, KEYS = 0, XPOS = 231, YPOS = 16, POS = {X = 231, Y =
16}, DUMMY = 1048807, RESULT = 0}, LMMOUSEEVENT = {MSG = 0, BUTTON =
0, WHEELDELTA = 0, X = 0, Y = 0, RESULT = 0, USERDATA = 0x0, STATE =
[]}, LMMOVE = {MSG = 0, MOVETYPE = 0, XPOS = 0, YPOS = 0, POS = {X =
0, Y = 0}, DUMMY = 0, RESULT = 0}, LMNOTIFY = {MSG = 0, IDCTRL = 0,
NMHDR = 0x0, RESULT = 0}, DRAWLISTITEMSTRUCT = {ITEMID = 0, AREA =
{LEFT = 0, TOP = 0, RIGHT = 0, BOTTOM = 0, TOPLEFT = {X = 0, Y = 0},
BOTTOMRIGHT = {X = 0, Y = 0}, VECTOR = {0, 0, 0, 0}}, DC = 0,
ITEMSTATE = []}, NMHDR = 0x1000e7}) at win32\win32callback.inc:3005#11
WINDOWPROC(396222, 512, 0, 1048807) at win32\win32callback.inc:3171#12
USER32!AddClipboardFormatListener at :0#13 USER32!CallWindowProcW at
:0#14 USER32!DispatchMessageW at :0#15 USER32!DispatchMessageW at
:0#16 APPPROCESSMESSAGES(0x19ba398) at win32\win32object.inc:553#17
HANDLEMESSAGE(0x196a3b8) at include\application.inc:1282#18
RUNLOOP(0x196a3b8) at include\application.inc:1419#19
APPRUN(0x19ba398, {Proc = {procedure (POINTER)} 0x162fdf8, Self =
0x196a3b8}) at include\interfacebase.inc:54#20 RUN(0x196a3b8) at
include\application.inc:1407#21 main at MapViewer_Demo.lpr:55 For
example you'll see that #2 CREATE is TCustomAction.Create in D:\fpc-
laz-asus\Lazarus\laz-svn-trunk\lcl\include\customaction.inc and the
current debugger will happily accept break points there.
The structure of my folders is
D:\fpc-laz-asus\FPC -> where all my versions of FPC reside
D:\fpc-laz-asus\FPC\3.0.6 -> Current development folder with
optimized make units
D:\fpc-laz-asus\FPC\3.0.6-dbg-bak -> Debug units/*.o and *.ppu +
some others
D:\fpc-laz-asus\FPC\3.0.6-dbg -> units/*.o and *.ppu for which we
want to trace code from Lazarus
Add -FuD:\fpc-laz-asus\FPC\3.0.6-dbg/units/i386-win32/* as last of the
-Fu of the fpc.cfg
For debugging parts of FPC, copy the desired *.o's and matching
*.ppu's from D:\fpc-laz-asus\FPC\3.0.6-dbg-bak to D:\fpc-laz-
asus\FPC\3.0.6-dbg respecting the folder tree hierarchy, when no
debugging required for the selected unit, delete the ppu and o from
the 3.0.6-dbg.
Lazarus program MUST be compiled Type of debug info : Dwarf with sets.
(-gw -godwarfsets)
How to do a build :
Adjust the .txt batch to your own requirement.
Start command line
Paste the top of the file to REM END OF SETTING UP COMPILE
ENVIRONMENT
Then depending on what you want to build, select the desired build
commands.
An important note, to avoid a complete cycle build, first do
CD rtl + make
then
CD packages + make
because otherwise there may be trouble.
Most of the time, except of course when things go wrong ;-), it works.
Ah yes, backups maybe of some use ...
----------------------------------------------------------------------
devEric69 · 2019-05-09 14:43
The debugging path of a simple TStringList. Add() method written as
follows...:
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i procedure
TForm1.btnTestClick(Sender: TObject); var oStrList: TStringList;
s1, s2: string;begin s1:='Hello'; s1:='Koukou'; oStrList:=
TStringList.Create; oStrList.Add(s1); oStrList.Add(s2);
FreeAndNil(oStrList);end; ... ➔ by adding files, one by one, in the
project inspector, starting with Classes.pp, then each *.inc file that
says it is "not found" (until it has been added in the project
inspector and its directory has been added in the -Fi of the project
options) is slippery, certainly, but especially very long: the *.inc
of FPC are fiting like "Russian dolls" between the *begin* and the
final *end.* of this unit .../.../fcp/rtl/unix/classes.pp. All this
end, for my part, with a global deprecated procedure that says that it
is "already declared forward" (?).
➔ so, I tried the "raw" method: a shell script that returns to me, on
the one hand the list of all paths of the .../.../fpc/rtl that contain
*.inc, and on the other hand the list of the .../...fpc/rtl directory
paths that contain *.p*, of which I only kept those that end with
.../unix, .../linux, and .../inc. I included them in their repective
tags (-Fu and -Fi) of the project's *.lpi. @BrunoK: Well, a compiler
is smart, but very complicated and downright obscure when, like me, we
haven't read "Compilers: Principles, Techniques, and Tools", commonly
known as the "Dragon Book" ==> In short, I encountered completely
obscure messages (possible that I put target-croos-compile paths
instead of others...) .
- finally, I came across this post (https://forum.lazarus.freepascal.o
rg/index.php/topic,41706.msg290002.html#msg290002), where GetMem and
wp each give their own solution.
@wp: your solution works perfectly with just a few *.p* units added.
But I see that just like me, in the case of a "container" unit of many
*.inc like Classes.pp, that it becomes random to be able to debug an
FPC class of the RTL, because they are exploded into too many pieces
of file-codes-*.inc.
@Martin_fr: the solution that works in any case is effectively to
reinstall with FCPUPdeluxe, which is very fast, with some compiler
options for, and FCP, and Lazarus. I've used this options (button
"Setup+ > Options override > FPC options && Lazarus options"): -O1
-gw2 -godwarfsets -gl ==> I can now debug step by step, anything I
want (RTL, ...) :