<div dir="ltr">Hi all,<br><br><div>I went through a couple of resources to understand the implementation of GDB server, RSP protocol <br></div><div>and how these things can be used for OSD-GDB server.</div><div><a href="https://sourceware.org/gdb/onlinedocs/gdb/index.html#SEC_Contents">https://sourceware.org/gdb/onlinedocs/gdb/index.html#SEC_Contents</a><br></div><br><div>A gdbserver acts as a bridge between GDB (the GNU debugger) and a System on Chip (SoC). <br></div><div>It accepts commands from GDB via a network port (TCP/IP) using the RSP protocol, <br></div><div>then translates those commands into a format understandable by the debug hardware <br></div><div>modules in the system being debugged.</div><br>The current implementation of gdb server in openOCD is generic and core-independent.<br><a href="http://repo.or.cz/openocd.git/blob/HEAD:/src/server/gdb_server.c">http://repo.or.cz/openocd.git/blob/HEAD:/src/server/gdb_server.c</a><br><br>The target specific details (for example, for OR1K) are listed here:<br><a href="http://repo.or.cz/openocd.git/tree/HEAD:/src/target/openrisc">http://repo.or.cz/openocd.git/tree/HEAD:/src/target/openrisc</a><br><div><br></div><div>As per my understanding, the complete software side in OSD should be something like this:</div><div><a href="https://pasteboard.co/HpZezKd.png">https://pasteboard.co/HpZezKd.png</a><br></div><br><div>The OSD-GDB server will be responsible for communication between GDB and OSD-GDB <br></div><div>server via TCP port using RSP protocol.</div><br><div>The major differences (as per my understanding) between the implementation of gdbserver in <br></div><div>openOCD and OSD system:</div><br><div>1. The bridge program uses the hardware drivers to send the translated commands to the <br></div><div>target system via an external JTAG cable in case of openOCD. We don’t need to support <br></div><div>JTAG or any other communication medium in the OSD-GDB server. <br></div><div>This part is handled by GLIP and osd-device gateway.</div><br><div>2. There are 2 data areas that are manipulated by GDB:</div><div><ul><li>Main memory. A uniform address space with 32-bit addressing. Provision for separate or unified instruction and data and instruction caches. Provision for separate or unified, 1 or 2-level data and instruction MMUs.</li><ul><li>This area can be accessed using MAM client class.</li></ul><li>Special Purpose Registers (SPRs). These registers provide all the administrative functionality of the processor: program counter, processor status, saved exception registers, debug interface, MMU and cache interfaces, etc.</li><ul><li>This area can be accessed using CDM client class.<br></li></ul></ul></div>3. An interface to connect it to the host controller (as mentioned in the image).<br><div>I think the general API for that part should be similar to osd_memaccess class.<span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"><br></span><a href="http://opensocdebug.readthedocs.io/projects/osd-sw/en/latest/02_developer/api/libosd/memaccess.html">http://opensocdebug.readthedocs.io/projects/osd-sw/en/latest/02_developer/api/libosd/memaccess.html</a></div><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">The target description is mentioned as:</p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="http://repo.or.cz/openocd.git/blob/HEAD:/src/target/openrisc/or1k.c#l53">http://repo.or.cz/openocd.git/blob/HEAD:/src/target/openrisc/or1k.c#l53</a></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">Also, something about the target description in an XML file is specified here: <br></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="https://sourceware.org/gdb/onlinedocs/gdb/Standard-Target-Features.html#Standard-Target-Features">https://sourceware.org/gdb/onlinedocs/gdb/Standard-Target-Features.html#Standard-Target-Features</a></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">I am looking more into this point. Please, if possible elaborate more about this point and <br></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">how it can be executed in the OSD-GDB server. <br></p><div><br></div><div>Also, suggest if I should continue the discussion over this topic on the mailing list or a PR with possible API would be better?</div><div><br></div><div class="gmail_extra">Thanks<br clear="all"></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font size="2" color="#666666"><b>Shivam Aggarwal</b></font></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 13, 2018 at 10:49 AM, SHIVAM AGGARWAL <span dir="ltr"><<a href="mailto:shivam16195@iiitd.ac.in" target="_blank">shivam16195@iiitd.ac.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><br><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jun 13, 2018 at 2:43 AM, Stafford Horne <span dir="ltr"><<a href="mailto:shorne@gmail.com" target="_blank">shorne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Shivam,<br>
<br>
As it was noted in Philip's mail it was suggested to work on the "CDM<br>
Client" class.  This will help define the software side API of the CDM<br>
hardware that the gdb-osd server will interact with.  In order to do<br>
that you may also want to think about what API (functions) would be<br>
required by the gdb server.  You can look at some example<br>
implementations of those.<br><br>
I would also suggest having a non gdb, more simple, debug interface.<br>
The gdb debug interface is quite complicated and makes a lot of<br>
abstractions via GDB.  Having a simple interface could make it easy to<br>
independently verify your "CDM client" class.  Is there something<br>
similar already for the MAM interface?<br></blockquote><div><br></div></span><div>We have completed the implementation of CDM client class. <br></div><div><br></div><div>Please take a look at the merged code:</div><div><a href="https://github.com/opensocdebug/osd-sw/blob/master/src/libosd/cl_cdm.c" target="_blank">https://github.com/<wbr>opensocdebug/osd-sw/blob/<wbr>master/src/libosd/cl_cdm.c</a></div><div><br></div><div>Associated tests: <br></div><div><a href="https://github.com/opensocdebug/osd-sw/blob/master/tests/unit/check_cl_cdm.c" target="_blank">https://github.com/<wbr>opensocdebug/osd-sw/blob/<wbr>master/tests/unit/check_cl_<wbr>cdm.c</a></div><div><br></div><div>A brief description of the API documentation: </div><div><a href="http://opensocdebug.readthedocs.io/projects/osd-sw/en/latest/02_developer/api/libosd/cl_cdm.html" target="_blank">http://opensocdebug.<wbr>readthedocs.io/projects/osd-<wbr>sw/en/latest/02_developer/api/<wbr>libosd/cl_cdm.html</a></div><div><br></div><div>Apart from the event part of CDM, CDM client class provides two important API(functions)- cl_cdm_cpureg_<wbr>read() and cl_cdm_cpureg_write() <br></div><div>functions  for easy interface with OSD-GDB server bridge. The two functions provide read/write register accesses by first updating the CORE_REG_UPPER register with the MSB of the SPR register (only if required), followed by an address translation from SPR register to CDM specific register and finally, a concluding read/write register request. <br></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For software a good reference implementation for a gdb server is the<br>
one from qemu:<br>
<br>
  - qemu - <a href="https://git.qemu.org/?p=qemu.git;a=blob;f=gdbstub.c" rel="noreferrer" target="_blank">https://git.qemu.org/?p=qemu.g<wbr>it;a=blob;f=gdbstub.c</a><br>
<br>
There is also a openocd gdb server implementation:<br>
<br>
  - <a href="http://repo.or.cz/openocd.git/blob/HEAD:/src/server/gdb_server.c" rel="noreferrer" target="_blank">http://repo.or.cz/openocd.git/<wbr>blob/HEAD:/src/server/gdb_serv<wbr>er.c</a><br>
<br>
Bother are self contained and not huge.<br></blockquote><div><br></div></span><div>Thanks for the referred implementation. I went through the implementation of openocd gdb server very briefly. <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>
<span class="m_9122081247106494500gmail-HOEnZb"><font color="#888888"><br>
-Stafford<br>
</font></span><div class="m_9122081247106494500gmail-HOEnZb"><div class="m_9122081247106494500gmail-h5">On Wed, Jun 13, 2018 at 1:27 AM SHIVAM AGGARWAL <<a href="mailto:shivam16195@iiitd.ac.in" target="_blank">shivam16195@iiitd.ac.in</a>> wrote:<br>
><br>
> Oh sorry. It was probably a misunderstanding on my part.<br>
> I will continue with the OSD-GDB server bridge. I have already opened an issue: <a href="https://github.com/opensocdebug/osd-sw/issues/19" rel="noreferrer" target="_blank">https://github.com/opensocdebu<wbr>g/osd-sw/issues/19</a><br>
> I am reading about RSP protocol and looking at the source code of openOCD for reference: <a href="http://repo.or.cz/openocd.git/tree/HEAD:/src" rel="noreferrer" target="_blank">http://repo.or.cz/openocd.git/<wbr>tree/HEAD:/src</a><br>
><br>
> Thanks a lot for your guidance and support.<br>
> Shivam Aggarwal<br>
><br>
> On Tue, Jun 12, 2018 at 9:35 PM, Philipp Wagner <<a href="mailto:philipp.wagner@tum.de" target="_blank">philipp.wagner@tum.de</a>> wrote:<br>
>><br>
>> On 06/12/2018 05:55 PM, SHIVAM AGGARWAL wrote:<br>
>>><br>
>>> Okay. I will complete the hardware implementation and get back to you soon. Also, I got access to Synopsys VCS through my institute's lab resources. I am currently learning how to use the tool.<br>
>>> So, please guide me about the testing part as well.<br>
>><br>
>><br>
>> Let's not do too many things at once. You started with the software part, and I'm proposing to continue down this path and finish it first before moving on to the next thing.<br>
>><br>
>><br>
>> Philipp<br>
>> ______________________________<wbr>_________________<br>
>> OpenSoCDebug mailing list<br>
>> <a href="mailto:OpenSoCDebug@lists.librecores.org" target="_blank">OpenSoCDebug@lists.librecores.<wbr>org</a><br>
>> <a href="https://lists.librecores.org/listinfo/opensocdebug" rel="noreferrer" target="_blank">https://lists.librecores.org/l<wbr>istinfo/opensocdebug</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenSoCDebug mailing list<br>
> <a href="mailto:OpenSoCDebug@lists.librecores.org" target="_blank">OpenSoCDebug@lists.librecores.<wbr>org</a><br>
> <a href="https://lists.librecores.org/listinfo/opensocdebug" rel="noreferrer" target="_blank">https://lists.librecores.org/l<wbr>istinfo/opensocdebug</a></div></div></blockquote></span></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">Shivam<br></div></font></span></div>
</blockquote></div><br></div></div>