Search code examples
multithreadingdebugginggdbzephyr-rtos

How does a debugger identify a thread?

When using a debugger to debug a mutli-thread application, the debugger usually shows the currently running threads. Either with some GUI or command like info threads.

But thread is an OS-specific concept. Though logically similar, each OS has a different implementation of thread.

According to here, gcc toolchain has the naming convention like this:

arch-vendor-(os-)abi

For example:

  • arm-none-linux-gnueabi (ARM toolchain for linux)
  • arm-none-eabi (ARM toolchain for bare-metal systems)

The arm part obviously shows that a debugger is architecture-specific. And there can be an optional part to specify OS.

Does a debugger need to have the intimate knowledge of the OS to understand the thread details for that OS? i.e. the debugger is showing software thread.

Or does the debugger just treat each processor core as a thread? i.e. the debugger is showing hardware thread. This approach seems more generic because it can work for different OSes on a same hardware architecture.

When I used some Zephyr RTOS specific gdb to connect to a board running Zephyr, I noticed it shows below information at the start.

enter image description here

So it seems the debugger does have some built-in knowledge for several RTOSes.

Is this for some OS-specific things like thread details? Or something else?

ADD 1 - 3:44 PM 5/1/2022

(Some understanding based on Employed Russian's reply.)

Quote from the libthread_db:

libthread_db is dependent on the internal implementation details of libthread. It is a "friend" of libthread in the C++ sense, which is precisely the "value added" by libthread_db. It encapsulates the knowledge of libthread internals that a debugger needs in order to manipulate the threads-related state of a target process.

So the libthread hides the thread implementation details of the underlying OS. And a debugger for that OS can leverage it.

As to below one:

Or does the debugger just treat each processor core as a thread? i.e. the debugger is showing hardware thread. This approach seems more generic.

No. Such approach would be entirely inadequate for debugging (you could have a multi-threaded program running on a single-core system).

It seems the debugger should be nice enough to provide some software thread abstraction to ease the debugging. But I think that can only be done for some well-known OSes. What if I wrote a unique OS that only I know the threading internals? Is that the bare-metal debugger such as arm-none-eabi (ARM toolchain for bare-metal systems)for?

Solution

  • Does a debugger need to have the intimate knowledge of the OS to understand the thread details for that OS?

    Not necessarily. The debugger could leverage libthread_db (part of the thread library implementation) which supplies the details of that particular implementation.

    i.e. the debugger is showing software thread.

    Yes.

    Or does the debugger just treat each processor core as a thread? i.e. the debugger is showing hardware thread. This approach seems more generic.

    No. Such approach would be entirely inadequate for debugging (you could have a multi-threaded program running on a single-core system).