[GSOC 2024] Proposal: Improving the userland debugging experience

AFAIK both GDB and LLDB rely heavily on ptrace non-standard syscall and signals to control and inspect processes(teams) and threads in those design.

Designing and implementing Haiku-specific ptrace may make porting modern debuggers and keeping them up to date much trivial.

see ticket: #9619 (Haiku does not have ptrace library) – Haiku

Designing and implementing Haiku-specific ptrace may make porting modern debuggers and keeping them up to date much trivial.

While porting .NET, I’ve noticed some minor features making use of ptrace on Linux or UNIX-like OSes.

At that time, I’ve considered somehow putting ptrace to libbsd or something like that. However, despite covering almost the same details, Haiku’s debug API has an entirely different way of control (a port instead of signals and waitpid). (This also prevents implement Haiku debugging on top of ptrace on Linux HyClone).

To get anything ptrace-like on Haiku, significant kernel-level changes are needed, including those to ensure that ptrace works peacefully with the current install_team_debugger.


As long as BMessages and asynchronous APIs are not involved, there should be a way. GDB and LLDB both seems to support Windows, which uses its own API.


Source stepping debugging is available for the native Debugger (I’ve used it personally many times), as long as gcc debug symbols are included. Also, start the app through Debugger and you get complete source lists, from where you set breakpoints.
$ Debugger app

I actually like the Haiku built in Debugger. The only missing feature would be inspection of std::vector elements.

I’ve also gotten source debugging to work on Haiku, but only for simple and natively compiled binaries.

I fully support this proposal and I’d like to articulate a case in favour of this, particularly on porting LLDB.


LLDB is used by the .NET diagnostic tools to perform dignostics and debugging on non-Windows platforms.
Yesterday I’ve managed to succesfully build netcoredbg on Haiku but it requires a few components from the .NET diagnostic toolset (namely libdbgshim) which, as said, require LLDB.
Netcoredbg is an implementation of a .NET debugger that does not have the licensing restrictions of the other debuggers available. JetBrains’ .NET Core debugger is part of Rider and is proprietary while Microsoft debugger cannot be used outside of the Visual Studio family of products.


The Debugger Adapter Protocol is a protocol specification targeted to abstract the communication between IDEs and debuggers.
LLDB supports DAP via lldb-dap (GDB also supports it but from version 14).
DAP is designed in a way similar to LSP (Language Server Protocol) which abstracts the communication between IDEs and language servers to get diagnostic, auto completion, refactorings, and more.
The Genio team is currently discussing the possibility to add the support for DAP but we don’t have a debugger which implements this protocol.
Porting LLDB would open a whole new world for debugging Haiku apps inside Genio being them written either in C++, C# or other languages.


That’s another nice use case for modern debuggers on Haiku!

In case anyone wonders, I have not abandoned this proposal in favor of the ARM64 port. I have submitted both to the GSoC 2024 program.

While I do have a slight preference towards the ARM64 port since learning how OSes interact with hardware and other architecture-specific mechanisms work aligns more with my mid-term ambitions, I believe the final project selection (if I am lucky enough to succeed this year) should be done by the Haiku org admins, representing the community interest.


Thank you so much for all your support! This project has been accepted into GSoC 2024!

It was quite a surprise to see this getting accepted instead of the ARM64 port, considering the amount of community interest in the second proposal. Maybe my skills and experience suit this project better :sweat_smile:

To keep things transparent: I’m having an unprecedented university workload, so I cannot promise an avalanche of progress right in the first half of May like in last year’s project. However, I will still try my best to get everything started whenever I have time, and hopefully we can see something interesting later this month, at the beginning of the official coding period (maybe a codebase of GDB14 that can compile).



1 Like

Congratulations, looking forward to contributions.

If I can add a feature request, examining (xray) iterators and arrays would be a must have addition to Debugger. Also, the ability to expand pointed user types would be a cherry on top to fully complete the debugging experience (eg. a class has a member called “Object *fInstance;” so it would be great if we can xray view fInstance members).

1 Like


It was quite a surprise to see this getting accepted instead of the ARM64 port, considering the amount of community interest in the second proposal. Maybe my skills and experience suit this project better :sweat_smile:

A good debugger is very needed. Maybe I will be able to finally fix my Smalltalk port

1 Like

There are videos from CPPCON about gdb and debugging, which can help:


1 Like

Amazing news! DAP is coming :smile:

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 :slight_smile:


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:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using
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
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
[Inferior 1 (process 20118) exited normally]

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.


Looks promising. At least more detailed than what Linux GDB does on HyClone process :slight_smile:


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

Any advices are welcome on how to improve/bypass the various issues :slight_smile:


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)