[Open SoC Debug] CDM: Next Steps

SHIVAM AGGARWAL shivam16195 at iiitd.ac.in
Sat Jun 23 20:08:00 CEST 2018


Hi Phillip,

Thanks a lot for the feedback. It helps.

On Sat, 23 Jun 2018, 20:55 Philipp Wagner, <philipp.wagner at tum.de> wrote:

> Hi Shivam,
>
> Am 23.06.2018 um 14:21 schrieb SHIVAM AGGARWAL:
> > I went through the implementation of gdbserver in openOCD and QEMU over
> > the last week.
>
> Great, you probably are now a bit confused, a bit enlightened and
> hopefully not overly scared. It's now time to get your hands dirty by
> writing code to try things out.
>
> > 4. *gdbserver.c*
> >
> > Here’s how this program will work:
> >
> > 1. The gdb server first connects with OSD host controller and verifies
> > the connection.
>
> What is the host controller doing here? And what do you mean by
> "verifies connection"?
>

By host-controller, I meant interface with osd-host controller. The
following API:
http://opensocdebug.readthedocs.io/projects/osd-sw/en/latest/02_developer/api/libosd/memaccess.html#c.osd_memaccess_connect
I believe I can first ensure the complete implementation of GDBserver on
GDB side.
Please see below for details.


> > 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.
>
> Step 1-6 are the standard setup setups for a TCP connection, nothing
> special here for GDB. You can find tons of code on the internet that
> shows and explains how that is done.
>

Yes, you are right. I have already read about it and hopefully, it won't be
much of a problem.


> > 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:
> > http://repo.or.cz/openocd.git/blob/HEAD:/src/server/server.c
> > http://repo.or.cz/openocd.git/blob/HEAD:/src/server/gdb_server.c
>
> I just read through
> https://www.embecosm.com/appnotes/ean4/embecosm-howto-
> rsp-server-ean4-issue-2.html,
> which quite well explains the GDB Remote Server protocol. Based on my
> (not exhaustive) understanding you need:
>
> 1) Code to listen to a TCP socket for incoming connections from the GDB
> (client).
>
> 2) Code to create and unpack the RSP packets according to the specs.
>
> 3) Code that does the actual work, i.e. that handles the commands GDB
> sends to the gdbserver instance.
>
> The first two parts are fundamental infrastructure which you cannot
> reduce in scope. Since the RSP protocol is rather old and not very fancy
> writing an implementation based on the specs should be viable.
>
> For part 3 you can reduce the number of supported commands to a minimum
> to demonstrate an initial solution, and/or hard-code some things instead
> of dynamically reading them from the target system.
>
> You can place all code required for this implementation in a new file
> e.g. osd_gdbserver.c/.h. You can then create a standalone application,
> e.g. osd-gdbserver, which uses this class (similar to osd-target-run,
> only much simpler).
>
> With these two parts you already should be able to have GDB connect to
> your gdbserver implementation. By issuing commands in GDB and seeing how
> they are received in your implementation it should be easier to make
> progress, since you can develop and test your work in a small little
> island instead of involving the full OSD stack.
>

So, as per my understanding, I should keep the things simple and smooth in
the
beginning. This would ensure a rough yet working solution in hand. As per
your
proposed implementation details, I believe we can divide the code as below:

osd_gdbserver.c: This file should contain all the API covering
connection(),
set_breakpoint(), get_breakpoint(), fetch_data(), RSP specific functions,
etc.
Also, I should making a or1k specific file and keep the things minimal.

osd-gdbserver.c: This should serve as a wrapper over osd_gdbserver.c to
call
all the essential functions in the program and start interfacing with both
GDB
and osd-hostcontroller.


> A final note of warning: you can of course copy code from other
> implementations, but please be aware of license restrictions. OSD is
> licensed under the MIT license, so you may take code from other projects
> which are MIT, BSD or public domain. You may not take code from GPL,
> LGPL or similarly licensed projects. If you are unsure please ask. (You
> can of course read and understand the source code, and then implement it
> on your own.)
>

That's really important piece of information.


> Philipp
>

I will start writing the code and open PR for the same soon.

Shivam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180623/967f7fc1/attachment-0001.html>


More information about the OpenSoCDebug mailing list