[Open SoC Debug] CDM: Next Steps
shivam16195 at iiitd.ac.in
Wed Jul 18 12:33:17 CEST 2018
I have completed the implementation of following commands in the GDBserver.
`g' -- read general-purpose registers
`G'XX... -- write general-purpose register
`p n' -- Read the value of register n
`P n...=r...' -- Write register n... with value r
`m'ADDR`,'LENGTH -- read memory
`M'ADDR,LENGTH`:'XX... -- write memory
I have added unit tests to check the functionality of intermediate
functions like encodeRSPpacket, etc.
I am trying to implement a *mock_gdbclient program* to test various
functionality of GDBserver. I am not thoroughly clear with the
implementation details of the mock_gdbclient program. I went through the
implementation of both mock_hostmod and mock_hostcontroller.
Based on my understanding and previous discussions, some utilities of the
1. It should be able to connect to the GDBserver via TCP.
For this part, I think I need to use functions from the *PThreads API *with
one thread running GDBserver. We need to run the client and the server part
simultaneously and hence, multithreading.
2. The program should respond to the queries/requests made by the
GDBserver. This part of the program essentially depends upon the connection
with the GDBserver.
It would be great if you could elaborate a bit on the specific details of
the establishing a TCP connection.
Coordinator | Electroholics
Event Head | Circuitrix Jr., Esya'18
Okhla Industrial Estate,Phase III
New Delhi, India - 110020
On Thu, Jun 28, 2018 at 2:22 AM, SHIVAM AGGARWAL <shivam16195 at iiitd.ac.in>
> I have worked on the following features of the OSD-GDB server:
> 1. Connection with GDB over TCP.
> 2. Send/Receive data to the client.
> 3. Send/Receive packet-data from the obtained buffer
> 4. Validate the packet-data using checksum
> I have opened a PR and will keep updating it with the rest of the features.
> Associated PR:
> I tested these features with GDB by compiling the code completely
> independent of
> the OSD framework. As a workaround, I used the below code for testing.
> All the features are working successfully.
> Is it possible to test the gdbserver using unit-tests (for example,
> something like
> Next steps:
> 1. To implement following use-cases/commands of the RSP protocol:
> `?' -- last signal
> `g' -- read registers
> `G'XX... -- write regs
> `m'ADDR`,'LENGTH -- read memory
> `M'ADDR,LENGTH`:'XX... -- write mem
> 'c' -- continue
> `z'TYPE`,'ADDR`,'LENGTH -- remove breakpoint or watchpoint (only, SW
> breakpoint (for now))
> `Z'TYPE`,'ADDR`,'LENGTH -- insert breakpoint or watchpoint (only SW
> breakpoint (for now))
> 's' -- step (optional)
> 2. To implement signal-handling. As per my understanding, we only need
> and SIGTRAP (for minimum support) to set software breakpoints, etc.
> Please provide some insight for this part.
> *Shivam Aggarwal*
> On Sun, Jun 24, 2018 at 12:37 AM, Philipp Wagner <philipp.wagner at tum.de>
>> Am 23.06.2018 um 20:08 schrieb SHIVAM AGGARWAL:
>> > I believe I can first ensure the complete implementation of GDBserver on
>> > GDB side.
>> > Please see below for details.
>> Yes, sounds like a plan.
>> > 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
>> > 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.
>> That sounds roughly right, but we need to discuss that based on the code
>> itself once it's there.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenSoCDebug