Annoying dialogs prompting to load symbols. Recently they have been updated to allow skipping all for the current session, yet these dialogs have not provided any option to silence for the local user.
Inability to do source debugging in many cases, especially cross-compilation, even with symbols properly configured.
Inability to debug JIT-compiled regions, even in assembly-only mode.
Random crashes, sometimes even before the debuggee fails. Sometimes I’m tempted to open another Debugger to debug that Debugger, which results in… another crashed Debugger.
There have been attempts to look for debugging alternatives for Haiku, including a GDB port. However, the port is known to not work and has a user giving a 1-star rating.
I’m thinking of solving this whole nightmare with a proposal that includes:
Porting GDB and LLDB. These are two popular debuggers with fairly different interfaces. Both provides many more complex features than Debugger, such as scripting.
With a working GDB and LLDB, improve and fix bugs for the native Debugger, as many as the time allows.
Document Haiku’s debugging API (install_team_debugger and whatever comes next). Haiku’s API is quite unique yet scarcely documented, except for the loosely related Debugger Kit.
It’s not like I’m a very heavy step-by-step debugger’s user my-self, but a proper tool to inspect the code, having watchers and the like is quite useful.
Debugger, despite its limitations, is already useful.
Having the possibility to switch to gdb would be great, or even having gdb’s feature (catch on throw, watching expressions, etc).
It is a great idea and will be very useful for Haiku software developers including me. Current Haiku Debugger is barely usable, it is too slow and buggy.
As you already implemented Haiku compatibility layer for Linux, your skills should be definitely enough to port recent GDB/LLDB to Haiku.
LLDB is well designed for portability and underlying LLVM libs ported enough so, running up the CLI part was relatively easy.
But I got stuck in wiring Haiku low level debugging APIs into the appropriate places and timings of LLDB without breaking LLDB’s logics or mechanisms.
I learned some lldb’s architecture and how Haiku debugging primitives work in my challenge, but more precise knowledge of the target debugger(GDB or LLDB) internal was needed.
I recommend you to fix the GDB integration because it used to work with the Haiku’s debugging APIs at its very old version.
I preferred LLDB as the better support of the Rust language expected which is important for porting Firefox.
Finally I built new powerful PC for porting Firefox, but I burnt out and too busy at work for a while.
Fixing/updating the GDB port may not be enough for a GSoC project. Since we already had a GDB port a long time ago, I expect that this can be completed in just a few days or maybe a few weeks, by looking at the existing code from back then and adjusting it to newer GDB versions.
Maybe I’m completely wrong with this (since I did not look closely into it for a long time), and that, in some way, major changes are needed in GDB or in the debug interface. In that case, your GSoC proposal will have to explain why it is so complicated. Or, if you decide to work with LLDB, an overview of how interfacing it to Haiku would look like.
Anyways, if anything, that means the project could spend more time for improving Debugger as well, and there, I think there are a lot of things to do, clearly enough to do at least one GSoC project.
Anyway, it seems like a good GSoC project idea.
To extend a bit on the history of GDB.
It has been used as the debugger for Haiku for a long time, before Debugger was developped. There is an old version of GDB, still maintained in Haikuports, that should still work fine at least with gcc2 apps. It is too old to handle newer debugging information from other compilers.
Besides these problems, GDB works fine on Haiku if you use it for cross-debugging (“target remote” or “target ext-remote”). I have used it occasionally with embedded devices development in that way.
I think this is a great GSoC idea to improve the debugging experience in Haiku and would be beneficial for many developers since there are indeed debugger crashes that are not very helpful in newer LLVM-based languages, there’s newer software written in Rust, Zig, Swift, etc and the native debugger seems to not understand the source information correctly during a debug session and always outputs the default assembler view.
We already have a GDB port and it has a native implementation of Haiku’s APIs other than the built-in Debugger application but I’m not sure how well it works with newer programming languages or apps built with DWARF5 information. The last time it was updated was 3 years ago and was stalled due to a crash after running a debug session and according to waddlesplash it was somewhat close to working but the crash remains unsolved. Depending on whether if you want to tackle this issue in your proposal is up to you. See: haikuports/dev-util/gdb/patches/gdb-8.1.patch at master · haikuports/haikuports · GitHub for the latest patches.
The GDB port can also be used as a guide to port LLDB which would be very useful for many of the newer LLVM-based languages and larger complex software that Haiku has as it support for debugging JIT code. Would really like to see LLDB ported and working in Haiku or to have newer language detection improvements to the existing native debugger.
It’s up to you on the specific scope this project. If you decide to go ahead with improvements to all the debuggers (GDB, LLDB, Debugger app) the suggestion I can give you is to prepare the GSoC proposal and research well in advance.
As @X512 also said, given your previous experience in your GSoC project with porting .NET and your low-level contributions and reports your skills are definitely suitable for completing this task.
KapiX actually figured out the use-after-free and documented his findings in the accompanying issue on HaikuPorts; it was just never actually added to the patchset. However, even after fixing that problem, there are still at least a few more remaining before GDB will actually work properly again, it appears. But yes, a newer GDB port is probably not very much work in the end.
A port of LLDB may also be interesting, but on the whole I am probably most interested in a working GDB and then improvements to the native debugger.
Sounds like a good idea overall, looking forward to your full proposal.
There is another point in which to review GDB support for x86/GCC2 and specific API symbolics and error mappings of Haiku.
As mentioned, a few things are documented - but there were a few things I’d fixed for GCC2 which were in the bug reports. Proper disassembly and symbolics…
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.
Eg.
$ Debugger app
I actually like the Haiku built in Debugger. The only missing feature would be inspection of std::vector elements.
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…
