[Open SoC Debug] CDM: Next Steps

SHIVAM AGGARWAL shivam16195 at iiitd.ac.in
Sat Jun 23 14:21:25 CEST 2018


I went through the implementation of gdbserver in openOCD and QEMU over the
last week.

The current implementation of gdbserver in OpenOCD is as diverse as it can
be. After a thorough study of each part, I think we need to work on
following program files for the complete execution.

1. *target.c*:
This program file will be responsible for providing an interface between
with the target CPU core. Setting breakpoints/watchpoints, reading/writing
memory, getting reg_list from the cpu core, target_call_event_* functions,
executing different target states { TARGET_UNKNOWN, TARGET_RUNNING,

This file will cover all the essential API from the following files:


2. *breakpoint.c:*
This program defines all the different attributes of
breakpoints/watchpoints, defines their state, and calls the respective API
from the target.c file.


Most of the API can be used directly from this program code.

3. *or1k.c*
In openOCD, there are separate files for each target. Each target handles
breakpoint/watchpoint settings, reading/writing to/from the register in
their own way. This program also provides the register map for OR1K. We
have to use CDM_cli and MAM_cli here to provide access to memory and


As a workaround, we can merge or1k.c with target.c due to lack of knowledge
about other CPU cores. But, this might be troublesome in the future while
extending gdbserver to other CPU cores.

4. *gdbserver.c*

Here’s how this program will work:

1. The gdb server first connects with OSD host controller and verifies the

2. On success, gdbserver waits for connection from client - GDB

3. It calls socket() to make a socket which will listen for connections.

4. It then calls bind() to bind our socket to the port number and listen()
to indicate that we want to accept incoming connections.

5. It then accepts the socket that has been created with socket() and bound
to an address with bind() and that is listening for connections after a
call to listen().
(add_service() function
http://repo.or.cz/openocd.git/blob/HEAD:/src/server/server.c#l203 )

The client will be added to the end of a linked list. This is to ensure
that we can connect TELNET as the client along with GDB to test our program.

6. It then accepts the connection and transfers the control to functions
for reading/writing data over TCP.

7. The rest program implements the API for RSP protocol and calls functions
from target.c to add_target, read/write registers, etc.

This program code accomplishes the above tasks:

Sidenote: I think that the complete implementation of OSD-GDB server is a
huge task. This part of the project is more time-consuming than expected.
This might delay certain items in the proposed timeline.

Recent blogs:
Understanding RSP protocol:
Learning GDB #1:
Learning GDB #2:

*Shivam Aggarwal*

On Fri, Jun 15, 2018 at 5:55 PM, Stafford Horne <shorne at gmail.com> wrote:

> On Fri, Jun 15, 2018 at 8:42 PM Philipp Wagner <philipp.wagner at tum.de>
> wrote:
> >
> ...
> > > The OSD-GDB server will be responsible for communication between GDB
> and
> > > OSD-GDB
> > > server via TCP port using RSP protocol.
> ...
> > > 3. An interface to connect it to the host controller (as mentioned in
> > > the image).
> > > I think the general API for that part should be similar to
> osd_memaccess
> > > class.
> > > http://opensocdebug.readthedocs.io/projects/osd-
> sw/en/latest/02_developer/api/libosd/memaccess.html
> >
> > yes, the osd_memaccess (like the osd_syslogger) class could be a good
> > starting point to take inspiration from.
> >
> > > The target description is mentioned as:
> > >
> > > http://repo.or.cz/openocd.git/blob/HEAD:/src/target/
> openrisc/or1k.c#l53
> > >
> > > Also, something about the target description in an XML file is
> specified
> > > here:
> > >
> > > https://sourceware.org/gdb/onlinedocs/gdb/Standard-
> Target-Features.html#Standard-Target-Features
> > >
> > > I am looking more into this point. Please, if possible elaborate more
> > > about this point and
> > >
> > > how it can be executed in the OSD-GDB server.
> >
> > I'll let Stafford answer that one, I don't know much about it.
> The target descriptor is what GDB uses to understand how to interact
> with the target,  this is part of GDB and you don't need to modify it.
> The target features is an XML file used by gdb to map the target
> registers and the register features.  By default the or1k-* gdb has a
> minimal feature xml.
>   https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> a=blob;f=gdb/features/or1k-core.xml;h=6fe9765150575464bf11a9752e3c32
> 76ff4ab8fa;hb=HEAD
> It is not required for the gdbserver (OSD-GDB server) to provide a
> feature set xml,  but it can provide one if the gdb-server knows more
> details compared to the default feature xml provided by gdb.   For
> example you can provide cache, mmu and spr's.
> I don't think this is required right now.
> > > Also, suggest if I should continue the discussion over this topic on
> the
> > > mailing list or a PR with possible API would be better?
> >
> > Design decisions can be done well on the mailing list. Once you have
> > first code that you need feedback on please open a PR.
> Yes, I prefer keeping these discussions in mail until everything is clear.
> -Stafford
> _______________________________________________
> OpenSoCDebug mailing list
> OpenSoCDebug at lists.librecores.org
> https://lists.librecores.org/listinfo/opensocdebug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180623/799bd38d/attachment.html>

More information about the OpenSoCDebug mailing list