This is the mail archive of the
mailing list for the GDB project.
Re: Need advice on writing gdb server for multiprocessor enviroment
On 2019-03-15 20:59, Artium Nihamkin wrote:
We have a multiprocessor embedded system with built in hardware
that interface through a GPIB (IEEE-488) connection.
A custom application acts as a debugger fronted and sends these GPIB
We were thinking of replacing this application with a gdb server with
eventual goal of debugging straight from a common, modern IDE. Using a
server seems like versatile and relatively easy to implement.
That's an awesome idea :)
The problem is that it is not clear how gdb, and specifically RSP,
with multiprocessor systems. Should we model each processor as a
The RSP doesn't really mandate anything, it depends how your programming
model works and at which level works. For example, if you debug
"bare-metal", modelling each processor/core as a thread is a common way
to do it.
If you have some kind of OS (even if really simple) that creates
thread/process-like things, you might want to model those as threads.
In the same way that when you connect to gdbserver running on x86, you
don't see the hardware cores as threads, you see the execution threads
of your program.
And if you have people who work at both levels (OS and appliation
level), nothing prevents you from offering both options.
The custom application has special commands such halting all processors
once, discovering which processors are present, getting the status of
processor (running/failed), XIO commands etc.
Additionally there are several memory types with overlapping address
that the debugger can read/write to.
Are these like separate data and program memories, or is there more to
Since gdb uses a simple numerical type when referring to addresses
(CORE_ADDR), it doesn't support multiple address spaces naturally. The
trick used so far by multiple architectures (in-tree, there is only AVR
I believe) is to uses high bits in the address to identify the address
space. These bits are then not shown when an address is printed, so the
user would not see them. It's just an internal encoding.
Can all these things work reasonably with gdb?
It all sounds like challenges that have been overcome in the past for
various architectures, so I would say yes.