Can’t you just add that symlink to the gdb package?
Nice idea, I haven’t thought of that.
Support for running GDB directly on Haiku is coming. Obviously a lot of cleanup is needed.
Unlike the old broken port, the inferior can be launched and debugged by GDB throughout its whole lifetime.
Code is not published yet? Are you using force push in GitHub - trungnt2910/gdb-haiku?
I’m always force-pushing. However, I intend to split the GDB commit into a separate one from gdbserver
.
There are a few final stubs I want to implement (currently 4 of them right now) before I’ll publish the code later today.
Code has been pushed.
GDB
is now usable for the general use case.
I want to deal with a few other things like signal frame handling and refine the two commits before making a HaikuPorts recipe.
How much work would it be to update to GDB 15 while you’re at it?
Can’t see any structural changes compared to the GDB 14 branch, so rebasing should be mostly trivial.
There are a few hacks I might want to remove after updating.
There are also a few interesting points in the changelogs for GDB 15:
* Debugger Adapter Protocol changes
** GDB now emits the "process" event.
** GDB now supports the "cancel" request.
** The "attach" request now supports specifying the program.
* New remote packets
New stop reason: clone
Indicates that a clone system call was executed.
QThreadOptions
Enable/disable optional event reporting, on a per-thread basis.
Currently supported options are GDB_THREAD_OPTION_CLONE, to enable
clone event reporting, and GDB_THREAD_OPTION_EXIT to enable thread
exit event reporting.
QThreadOptions in qSupported
The qSupported packet allows GDB to inform the stub it supports the
QThreadOptions packet, and the qSupported response can contain the
set of thread options the remote stub supports.
A few changes when updating to GDB 15:
- Removed the
gdbserver
hack that swallowsTHREAD_EXITED
events. - Fixed the
configure
script to detectsocketpair
support on Haiku. - Some
Makefile
changes following a recent patch that demands headers with names conflicting with Haiku system structs to be included on the command line. - A refactor of
solib-haiku.c
to match the internal API upstream. - Other misc. fixes following the modernization of the rest of the C++ codebase.
That is great news. There are external tools like QtCreator which link to gdb for debugging, so these toolchains become more usable with Haiku. I really like the native Debugger, however it doesnt handle containers and iterators which makes deep investigations more difficult.
Thanks again, the OS and ecosystem get better each iteration.
/boot/system/develop/headers/os/kernel/OS.h:321:3: error: conflicting declaration 'typedef struct thread_info thread_info'
321 | } thread_info;
| ^~~~~~~~~~~
In file included from ./../../source/gdbserver/server.h:199:
./../../source/gdbserver/gdbthread.h:30:8: note: previous declaration as 'struct thread_info'
30 | struct thread_info
| ^~~~~~~~~~~
/boot/system/develop/headers/os/kernel/OS.h:424:33: error: conflicting declaration of 'void debug_print(const char*, ...)' with 'C' linkage
424 | extern void debug_printf(const char *format, ...)
| ^~~~~~~~~~~~
In file included from ../../source/gdbserver/../gdbsupport/common-defs.h:203,
from ./../../source/gdbserver/server.h:22:
../../source/gdbserver/../gdbsupport/common-debug.h:36:13: note: previous declaration with 'C++' linkage
36 | extern void debug_printf (const char *format, ...)
| ^~~~~~~~~~~~
/boot/system/develop/headers/os/kernel/OS.h:426:33: error: conflicting declaration of 'void debug_vprintf(const char*, __va_list_tag*)' with 'C' linkage
426 | extern void debug_vprintf(const char *format, va_list args);
| ^~~~~~~~~~~~~
../../source/gdbserver/../gdbsupport/common-debug.h:43:13: note: previous declaration with 'C++' linkage
43 | extern void debug_vprintf (const char *format, va_list ap)
| ^~~~~~~~~~~~~
Makefile:577: recipe for target 'nat/haiku-nub-message.o' failed
make[2]: *** [nat/haiku-nub-message.o] Error 1
make[2]: *** Waiting for unfinished jobs....
I’ve force-pushed the fixes to the GDB 15 branch.
It still stops at every thread creation that do not happen on Linux. Step into operation is not working (tested in gdbgui
and Netbeans).
Acknowledged, will look into that right after I gain access to my devices.
It still stops at every thread creation that do not happen on Linux.
The latest branch contains the fixes. I made the fundamental mistake of mapping Haiku’s B_DEBUGGER_MESSAGE_THREAD_CREATED
directly to GDB’s TARGET_WAITKIND_THREAD_CREATED
. The former is an event belonging to the parent thread, the latter belongs to the new thread.
The new code only uses B_DEBUGGER_MESSAGE_THREAD_CREATED
as a hint, then translates the hinted thread’s first B_DEBUGGER_MESSAGE_THREAD_DEBUGGED
to TARGET_WAITKIND_THREAD_CREATED
.
This issue should now be fixed in both GDB and gdbserver
.
Step into operation is not working.
Can you provide a minimal code example that triggers this issue?
Try to call “step into” operation when calling some function. It should go inside function.
Step into operation works fine in Netbeans with Linux GDB.
I can reproduce this issue now. Trying to find the root cause and working on a fix.
Instruction-level step into (stepi
) should work as expected. However, for source-level stepping, GDB emits one step request, then if that instruction does not correspond to a source line, GDB seems to allow the thread to run freely until hitting the next line of the same function.
The Haiku version of GDB currently does not recognize many function calls as being in the source file (and therefore reach that function’s body) but instead sees a PLT entry after single stepping. It then continues through this PLT entry, eventually reaching the next source line in the calling function.
This also seems to be a frontend issue (probably some misconfiguration in haiku-tdep.c
) rather than a backend issue (a bug in haiku-nat.c
), since this issue does not appear when debugging using the Linux GDB frontend attached to gdbserver
.