Need advice on writing gdb server for multiprocessor enviroment

Need advice on writing gdb server for multiprocessor enviroment

[Artium Nihamkin]

Hi,

We have a multiprocessor embedded system with built in hardware debugger
that interface through a GPIB (IEEE-488) connection.

A custom application acts as a debugger fronted and sends these GPIB
commands.

We were thinking of replacing this application with a gdb server with the
eventual goal of debugging straight from a common, modern IDE. Using a gdb
server seems like versatile and relatively easy to implement.

The problem is that it is not clear how gdb, and specifically RSP,  works
with multiprocessor systems. Should we model each processor as a thread?
The custom application has special commands such halting all processors at
once, discovering which processors are present, getting the status of each
processor (running/failed), XIO commands etc.
Additionally there are several memory types with overlapping address spaces
that the debugger can read/write to.

Can all these things work reasonably with gdb?



Thank you,
Artium

Re: Need advice on writing gdb server for multiprocessor enviroment

[Simon Marchi]

On 2019-03-15 20:59, Artium Nihamkin wrote:
> Hi,
> 
> We have a multiprocessor embedded system with built in hardware 
> debugger
> that interface through a GPIB (IEEE-488) connection.
> 
> A custom application acts as a debugger fronted and sends these GPIB
> commands.
> 
> We were thinking of replacing this application with a gdb server with 
> the
> eventual goal of debugging straight from a common, modern IDE. Using a 
> gdb
> 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,  
> works
> with multiprocessor systems. Should we model each processor as a 
> thread?

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 
> at
> once, discovering which processors are present, getting the status of 
> each
> processor (running/failed), XIO commands etc.
> Additionally there are several memory types with overlapping address 
> spaces
> that the debugger can read/write to.

Are these like separate data and program memories, or is there more to 
it?

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.

Simon