This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need advice on writing gdb server for multiprocessor enviroment


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]