I am new to Haiku. I am looking at haikuports/app-text/mandoc to see if I can get makewhatis and apropos working. The code is pretty intense but I’ve got a rough idea of what is going on.
Instead of littering printf() calls all about, a nice debugging GUI session would be great. In digging about I see that there is gdb and something called QTcreator, which I have installed. With the setup in haikuports I am not sure how to point a debugger to the source files and all. Let alone how to start a debugger. I have learned that to build things in debug I needed to edit the .recipe file and add to the build target -DCMAKE_BUILD_TYPE=debug and rebuild.
Any ideas, guidance, or suggestions would be appreciated.
If you have build in debug version, you can try the native Haiku Debugger app.
[Documentation de Debugger dans le User Guide](file:///boot/system/documentation/userguide/en/applications/debugger.html)
Launch the makewhatis / apropos command from the start window, you can either attach to an already running process or launch a new one, giving you time to setup some breakpoints before the program start to run.
On loading, you will get dialog asking you if you want to load the debug version of some system and foundation libs, for the moment try without.
If the source file is not displayed, you can click above on the text saying “No source file…” to help locate the source file.
OK. I run the Debugger on the file created in the build at ~/haikuports/app-text/mandoc/work-1.14.6/sources/mandoc-1.14.6/mandoc As it runs under different names through symlinks to the executable with internal logic based on the main argv[0] name I honor that with a
symlink of ln -s mandoc makewhatis
That way it supports multiple shell commands with one unified set of source files all sharing common definitions and logic.
In running: Debugger makewhatis
No source displayed. Your suggestion of clicking on the text ‘Source not available’ does nothing, and checking with what is displayed I cannot find a source-related control.
Am I missing something? BTW, the file you reference has a link in it :
Debugger Reference Manual which when clicked gives a security warning. I cannot get what it says it is pointing to.
So I do not have a link to a Debugger Reference Manual. Is there one on the Haiku site?
Some progress.
Going through that at the “Debug > Start Debugging” step I get a QTcreator error
with options to Terminate, Debug and the like for QTcreator itself.
Still no debugger with source showing.
Any thoughts/clues?
file mandoc
mandoc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Note no “with debug_info”
Of course no debugger will work with it.
I learned that following Debug HaikuPorts | Haiku Insider
led me down the wrong path.
Just adding -g to CFLAGS does it. Just as I remember things doing in my past.
Now the debugger shows source.
Off to setting breakpoints.
My bad. I believed the Haiku Insider page about the CMAKE setting. I know about the -g CFLAGS setting from my years of writing Makefiles. The more I learn, deep down it’s not all that different from other systems. Things are just packaged differently.
OK. Now that I have things running, I opened the main.c file in the debugger and set a breakpoint ar the main() routine. Having done that I assumed that the Debug button would start things out. Nope. I get a popup that says ‘Team 397 has terminated’. I’m not clear on this ‘team’ thing here, when all I want to do is start the program so I can step through things and set breakpoints.
I have done a lot of searching but no results that give me clues on how to proceed. Just starting the program should be straightforwards, right?
Team is the terminology used by BeOS and therefore Haiku to designate processes.
Aka programs.
Do you start the program to debug via the Start new button or you start the program from terminal and then use the Attach button ?
I suggest to use the “start new team” , setup your breakpoint and then hit the Run button.
The debug button is when you want to stop for inspection the selected thread in the lists of threads at top left of the window, and that thread is currently running.
In your case, the process probably have only one single “main” thread.
If it report no thread to debug, it means that the thread has already ended. If it’s a mono threaded program, that also means the process has already exited.
Main difference since then is that if you define a debug build you NEED to define the debug package also in the recipe, the other way is also true, if you use defineDebugInfoPackage in your recipe and use -DCMAKE_BUILD_TYPE=Release haikuporter will fail and give you an error.
The whole “use argv[0] to control what command to be” makes debugging this one a pain. You can’t debug the non-default branches from a gui debugger, because it won’t have a command line?
What I’d do is put in a force at the main branchpoint to force it into ‘makewhatis’ by default so you can see what it does in that branch?
EDIT: or write ‘makewhatis’ to argv[0] if the compiler will let you.
Can’t test now, but I think it’s doing what you ask it to do.
When you start a new process from the debugger, I believe it is stopped in main. That way you can set your breakpoints and whatever. When you click the Run button you are telling it to continue from where it is. It finds no more breakpoints and runs to the end. So add more breakpoints if needed, or use the Step buttons.
That said, both apropos and makewhatis work right for me.
No. A debugger cannot enter an executable until told to, I have several breakpoints set after the initial main() one, and the same ‘terminated’ result. None of them triggered.
I agree with you that running off of argv[0] is a hacks way to share code across multiple executable commands. A library would have been my first choice.
What they overloaded with this trick is:
ls -l /bin|grep mandoc
lr-xr-xr-x 1 user root 6 May 8 17:27 apropos → mandoc
-r-xr-xr-x 1 user root 283192 May 8 17:27 demandoc
lr-xr-xr-x 1 user root 13 May 8 17:27 makewhatis → ../bin/mandoc
lr-xr-xr-x 1 user root 6 May 8 17:27 man → mandoc
-r-xr-xr-x 1 user root 595216 May 8 17:27 mandoc
lr-xr-xr-x 1 user root 6 May 8 17:27 whatis → mandoc
Maybe doing this saves some space, but at what cost?
You are right. That was in 32 bits with mandoc 1.14.3. In a clean, updated 64 bits system they do nothing.
For the rest of this message, please note I’ve only ever used the debugger for stack traces of locked programs. I’m no expert.
The debugger starts the program stopped in… somewhere. Points to somewhere near eqn_box but no explicit place. Blindly stepping through it I see getprogname and a bunch of strcmp, that may well be the checks in main for the name, but the debugger never points there.
Let’s link as makewhatis and see if that changes anything. At some point it reaches mandocdb and seems to be doing something, so it seems those really were the checks in main.
Let’s try again and rebuild without -O2 -pipe. Debugging info and optimizations may give surprising results, like variables and code that don’t exist because they are optimized out. gcc suggests using -Og with -g, unless you have good reasons not to. And now we see it at the start of main right away.
It seems the loop in treescan always goes through the not-a-regular-file path.
(which I’m not)