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]

Bare metal gdb stub/server implementation


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

 		 	   		  

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