I’ve noticed that for the most part I have to manually browse to the source in the debugger. Which is a huge time sink. It seems to have a relative path to the home folder stored in the binary but can’t resolve that automatically at debug time.
Is there a way to make them absolute? Or get the debugger to resolve paths successfully all the time?
The path is generated by gcc, so if you path absolute paths to gcc, you get absolue paths in the binary.
On Debugger side, the logic to resolve relative paths can certainly be improved, once you have set the base directory for one file, it could deduce the path for other files relative to that, for example?
Ok I’ll have a play around with my make files and see what I can do with the paths.
Is there an easyish way to make custom builds of the debugger? Like how high is the barrier of entry to working on the debugger?
No magic involved.
After getting the Haiku source code from the Git repository and configuring it using the configure script (following instructions here: Building Haiku | Haiku Project):
jam -q Debugger
(add -j4 to build on 4 CPUs in parallel for faster builds if you want)
The sourcecode for Debugger is in src/apps/debugger
The code for locating the sourcecode is here (several functions starting from this one): TeamWindow.cpp « team_window « gui « user_interface « debugger « apps « src - haiku - Haiku's main repository
It will attempt to locate the sourcefile using a query based on the name, that should work unless you have queries disabled on the partition where you store your sourcecode (unfortunately not an uncommon thing to do, since partitions without queries are a little faster). Then if that fails, it will let you find the sourcefile manually.
I’ve installed hrev57774 x64 on my new bare metal box. And the debugger’s gotten significantly worse in terms of finding source. Most of the stack frames in my code are now just “Source file unavailable”. This is after I rewrote my makefiles to pass absolute paths to the compiler. It doesn’t make any sense.
When it does find the file, clicking on the file name does a recursive search and gives me a menu of options. That part is much better. About as good as it gets if it’s not going to find the file directly.
So to do any work I have to fix the debugger… sigh.
Example command line:
g++ -I./src -I../include/lgi/haiku -I./resources -I../include -MMD -MP -fPIC -fno-inline -g -fpermissive -std=c++14 -g -D_DEBUG -DHAIKU -D_REENTRANT -D_GNU_SOURCE -DHAS_LIBSSH=1 -c /boot/home/code/lgi/trunk/lvc/src/BrowseUi.cpp -o Debug/BrowseUi.o
Does the link command matter at that point?
That seems to be building the release build… how do I switch to a debug build?
You canconfigure parts of Haiku to be built in debug mode by creating and editing the file build/jam/UserBuildConfig. In particular, “SetConfigVar debug” lines can be used. There is a readme and sample file in the build/jam directory that explain how to use this.
Ok, I’m finally digging into the root cause of all these missing paths. And mostly just using printf. But the issue I’m having is that once I add logging to libdebugger.so it doesn’t show up at runtime.
I thought that copying the .so into the same folder as the executable would cause it to be loaded before the system .so? Is that a thing? How would I check what .so ACTUALLY got loaded? Is there a command that lists the shared objects loaded by a process?
You can put it into lib/ next to the executable. not right next to it.
Alternatively $HOME/config/non-packaged/lib is available i think.
In any case the command listimage will show all loaded images, and which shared libraries are loaded.
The ./lib location didn’t work for me. But symlinking non-packaged/lib to the right file DID work so all good. Also nice to know about the listimage… very helpful.
Ugh… so I think I’m getting somewhere with this. A lot of the symbols are failing to be demangled. So maybe that’s got something to do with why it can’t map a stack trace (which is demangled ok?) back to a source file.
~> g++ --version
g++ (2023_08_10) 13.3.0
I think I’ll investigate haiku\src\add-ons\kernel\debugger\demangle\gcc3+.cpp and see if it needs to be updated to handle g++ v13 mangled names.
An example name it fails to parse:
_ZN6icu_74L14unames_cleanupEv
However:
~> c++filt -n _ZN6icu_74L14unames_cleanupEv
icu_74::unames_cleanup()
Why even roll our own? Can’t we use some official demangler?
Also:
I’m finding that DwarfUtils::GetDeclarationLocation fails.
It’s likely that something in DwarfFile::_ParseDebugInfoSection is not right…
The stack trace is only demangled in the UI. The symbol names are still mangled internally, of course. And source file mapping happens via the mangled symbols not the demangled ones, if I understand correctly. So this is an unrelated problem.
After some more investigation it seems that the dwarf debug info parsing in the debugger is just well broken. I’ve been adding the tracing and grepping for various files and symbols that are in the binary and they don’t appear. I also get various errors when I instrument the code with WARNINGs:
../src/kits/debugger/dwarf/DwarfFile.cpp:2002 Invalid DW_FORM_line_strp offset: 661249 of 4796
../src/kits/debugger/dwarf/DwarfFile.cpp:2269 _ParseLineInfoFormatString err at 0 of 2
Obviously those lines numbers are approximate, as I’ve added logging.
The files / symbols in question are absolutely in the binary. I’ve checked using readelf which shows they are present. The Debugger however skips or misses them during parsing. To dig any further I’d have to start to understand the parser and the Dwarf v5 format in more detail. Did anyone actively work on the Dwarf parser lately?
The raw binary is here and I’m expecting it to have the constructor AppWnd::AppWnd in the file LgiIde.cpp but it’s just not there.
Yes, @davidkaroly did some work for dwarf5.
https://cgit.haiku-os.org/haiku/log/?qt=grep&q=dwarf