[GSOC 2024] Proposal: Improving the userland debugging experience

Can’t you just add that symlink to the gdb package?

1 Like

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.

18 Likes

Code is not published yet? Are you using force push in GitHub - trungnt2910/gdb-haiku?

1 Like

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.

1 Like

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.

13 Likes

How much work would it be to update to GDB 15 while you’re at it? :slight_smile:

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.
7 Likes

A bit of work, but not too much :penguin:

trungnt2910/gdb-haiku at gdb-15-haiku (github.com)

7 Likes

A few changes when updating to GDB 15:

  • Removed the gdbserver hack that swallows THREAD_EXITED events.
  • Fixed the configure script to detect socketpair 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.
11 Likes

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.

5 Likes

It still stops at every thread creation that do not happen on Linux. Step into operation is not working (tested in gdbgui and Netbeans).

1 Like

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.

2 Likes

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.

1 Like

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.

1 Like