I fully support this proposal and I’d like to articulate a case in favour of this, particularly on porting LLDB.
.NET
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.
DAP
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
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).
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).
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
A good debugger is very needed. Maybe I will be able to finally fix my Smalltalk port…
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
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.
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)
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.
