Bare metal gdb stub/server implementation

Bare metal gdb stub/server implementation

[Juha]

I have tried to find the answer by googling, in manuals and tried asking in
freenode chat (#gdb) but haven't come up with an answer...
 
Where could I find the "right" way to handle things like process IDs and
thread IDs in a bare metal case, where there really are no processes or threads?
 
I'm trying to put together a standalone gdb stub/server for Raspberry Pi B2.
(I'm not sure what to call it: it has stub functionality, but is standalone
and as such works like a server.)
 
I have started with a single core, and maybe one day I'll expand to all 4 cores.
 
Should I fake the gdb client that there are processes or threads? If,
then which way would be better: single process with 4 threads (= cores) or
4 processes without multithreading support? Maybe there is still a better option?
 
Also, now, when my 'stub' starts and gdb client asks for reason for halt ('?'),
I respond that a program has finished (W 00). Is that a good choise?
 
-Juha Aaltonen

 		 	   		  

Re: Bare metal gdb stub/server implementation

[Duane Ellis]

> I'm trying to put together a standalone gdb stub/server for Raspberry Pi B2.
> (I'm not sure what to call it: it has stub functionality, but is standalone
> and as such works like a server.)


Are you sure you are talking about bare metal on raspberry pi?
I think you mean Linux Kernel debug (not application debug) via JTAG

Take a look at the open source JTAG solution called “OpenOCD”

Specifically look at the “rtos” directory for linux stuff.

-Duane