This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Bare metal gdb stub/server implementation
- From: Juha <turboruuvi at hotmail dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Sat, 26 Sep 2015 02:51:59 +0300
- Subject: Bare metal gdb stub/server implementation
- Authentication-results: sourceware.org; auth=none
- References: <DUB122-W730C2001FD91F22F856C4DC420 at phx dot gbl>
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