Amazing news! DAP is coming 
1 Like
Nice going, looking forward on your progress, congrats! +1
1 Like
We spent some time discussing this with the other mentors. The main reason we went with this one is that we are limited by our number of available mentors this year (there were several very good proposals, and also some of the usual mentors were not available this year for personal reasons), and the people comfortable with mentoring the ARM64 port (me and korli, mainly) were allocated for other projects. So, basically, picking this project allows us to accept one more student, and still assign everyone a mentor who has the right expertise.
So it will be Waddlesplash doing double duty, which is a bit easier for him since he’s working full-time on Haiku and not combining it with another job.
I know I said previously that we would figure a way to make the ARM64 proposal work, but it looks like I was a bit too optimistic about mentor availability. Or too pessimistic about the number of good applications we got, depending on how you want to see it 
10 Likes
Sorry for the very slow update, but I have made some progress with porting GDB.
The old patchset crashed for mysterious reasons even after applying some known fixes. I therefore decided to start a new port from scratch based on the GDB 14 source tree.
I’ve also decided to work with gdbserver first, since it requires a less overwhelming subset of debug operations implemented.
gdbserver can now launch a “Hello World” Haiku process and exit cleanly.
Logs from a gdb client running on Linux:
trung@DESKTOP-5OCA2N2:~$ gdb -ex "target remote $VM_HOST:6969"
GNU gdb (Ubuntu 13.1-2ubuntu2.1) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using 192.168.154.176:6969
Reading /boot/system/bin/bash from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /boot/system/bin/bash from remote target...
Reading symbols from target:/boot/system/bin/bash...
(No debugging symbols found in target:/boot/system/bin/bash)
0x0000020baa6a6a71 in ?? ()
(gdb) continue
Continuing.
process 20118 is executing new program: /boot/home/Desktop/test
Reading /boot/home/Desktop/test from remote target...
Reading /boot/home/Desktop/test from remote target...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x000001812883aa71 in ?? ()
(gdb) continue
Continuing.
[Inferior 1 (process 20118) exited normally]
(gdb)
I am now working on getting gdbserver to load the target’s library lists, before trying to poke around with things like breakpoints to reveal the rest of the stubs. Then I’ll move on to the full GDB.
11 Likes
Nice to see some progress on this topic : )
I’ve recently jump into the Haiku world by installing it on an Intel NUC from 2017. Indeed I’ve noticed the standard “Debugger” tool is having some issues.
Below are some screenshots of tentative to debug Nifskope (debugging symbols were added in the executable.
file ./NifSkope
./NifSkope: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped
-
Annoying warning messages about source code for libs not available (which I don’t need for my debugging)
-
Only part of the cpp source files are available in the Debugger
-
Breakpoints are working fine however the display of the code is in assembler (side effect of below point)
Any advices are welcome on how to improve/bypass the various issues
2 Likes
Are you running beta4? The nightlies have seen a number of fixes to Debugger here which I think fix some of these issues.
1 Like
Yes only using the beta4 at the moment. Ok I will have a look at the nightlies (not sure how to retrieve the latest source only for Debugger)
apart from the dark blue on black 
A few other things I want to look at (attach, SIGKILL, fork()), before trying to get symbols and source files to actually work.
Then, it might be possible to hook up gdbserver to VSCode on a remote machine, offering a competitive way to develop for Haiku.
5 Likes
Support for gdbserver on Haiku is mostly complete. Teams, threads, and images are recognized. Debug symbols can be loaded. Registers and memory can be accessed. Messages printed by debugger are correctly transferred to the client.
Adding something like xfer_osdata to query Haiku primitives like ports, areas, semaphores, and so on might be desirable, but it would take quite a bit of work serializing them all to XML, so I might consider that if I have time and if there’s high demand for it.
There are a few kernel-level modifications that I want to do as well. I’ve discussed them with waddlesplash and I’ll take a look at them in the next few days. Then hopefully, after my exams, I can write a blog post about all the implementation details (the overall idea is similar to the old GDB port, but the design has significantly diverged since I wrote everything from scratch). After that I’ll port the GDB frontend before moving on to this project’s next stage.
20 Likes
Fun fact: The syscall that seems like just a joke, is_computer_on, is called every time fork is called! The call is made through an inlined utility function called undefer_signals:
8 Likes
QtCreator is a good IDE for Haiku, but requires a working gdb for visual debugging. I hope your project will eventually allow this tool to work.
1 Like
You have my attention with vscode gbdserver.
Thank you for the hard work
1 Like
What is /usr/lib/debug?
Hmm, somehow I would need to move this to /boot/system/develop/debug. I wonder if gdb or gdbserver is responsible for these paths.
Seems like we can use --with-additional-debug-dirs /boot/system/develop/debug during configure, or set debug-file-directory /boot/system/develop/debug at runtime to point GDB to the correct debug directory.
However, gdb refuses to look just for ${DEBUG_DIR}/${DEBUG_INFO_FILE_NAME}. It always looks for ${DEBUG_DIR}/${PATH_TO_LIB_RELATIVE_TO_SYSTEM_ROOT}/${DEBUG_INFO_FILE_NAME} instead:
We either have to patch gdb to accept Haiku’s “flat” way of organizing .debuginfo files, or modify Haiku to symlink /boot/system/lib/.debug to /boot/system/develop/debug (which is more compatible with official GDB clients).
1 Like