[Open SoC Debug] Good Summer of Code - I am your mentor

Philipp Wagner philipp.wagner at tum.de
Mon May 7 09:10:01 CEST 2018


Hi Shivam,

I've forwarded this to the opensocdebug mailing list, please keep all 
technical discussion there.

On 05/06/2018 10:07 PM, SHIVAM AGGARWAL wrote:
> Hi,
> 
> Thanks for reviewing my PR. I understood all the changes and will update 
> them shortly. I read about or1k debug registers thoroughly and very 
> briefly about GDB internals. Please clear thesefew basic queries about 
> the project.
> 
> 
> *My understanding of GDB and debugging system*:
> 
> GDB helps in setting watchpoints and breakpoints in the program code to 
> debug the program running on the soft-CPU core (here, or1k).
> 
> 
> A breakpoint is a user-designated location in the program where the user 
> wants to regain control if program execution ever reaches that location.

yes

> A watchpoint is a location where the user just wants to see the program 
> state without actually breaking the program flow.

no, a watchpoint is a break based on the value of a variable.

> Now, for instance, I want to set a breakpoint at line 5 in the below 
> code. This address value is loaded (write operation) into one of the 
> registers mapped in CDM module, which in turn is transferred over or1k 
> debug register (DVR-DCR pair). Now, during program execution, if the 
> program counter ever matches a value in a breakpoint register (read 
> operation), the CPU raises an exception and reports it to GDB.

Yes. Note that the "raises an exception and reports it to GDB" part 
requires more actions in between, since GDB cannot magically know that 
an exception happened. That's why you need to send out an debug event 
packet in this case.

> 1. #include <stdio.h>
> 2. int main()
> 3.   {
> 4.   // printf() displays the string inside quotation
> 5.   printf("Hello, World!");
> 6.   return 0;
> 7.    }
> 
> 
> This Breakpoint location address will be stored in DVR (Debug Value 
> Register) and its corresponding Data Control Register value will be:
> 
> 
> 
> Bit
> 
> 	
> 
> 31-8
> 
> 	
> 
> 7-5
> 
> 	
> 
> 4
> 
> 	
> 
> 3-1
> 
> 	
> 
> 0
> 
> Value
> 
> 	
> 
> Reserved
> 
> 	
> 
> 010
> 
> 	
> 
> 0
> 
> 	
> 
> 001
> 
> 	
> 
> 1
> 
> Comments
> 
> 	
> 
> No need to worry about this value.
> 
> 	
> 
> Compare to Load EA
> 
> 	
> 
> Compare using unsigned integers
> 
> 	
> 
> 001 Equal
> 
> 	
> 
> Corresponding DVR/DCR pair is present
> 
> 
> “The DCRs are programmed with the watchpoint settings that define how 
> DVRs are compared to the instruction fetch or load/store EA or to the 
> load/store data.”
> 
> 
> Queries:
> 
>  1.
> 
>     I have decided these values based on the document (chapter 10)
>     https://openrisc.io/or1k.html. Some of these values (bits 1-4) can
>     be set as default. Which part of the project will be responsible to
>     set these values?

I don't understand the question. What do you mean by "which part of the 
project"?

>  2.
> 
>     Why are we mapping these DCR registers to OSD specific registers. We
>     can first store breakpoint address into OSD registers (write
>     operation) and then set the above values into the or1k debug
>     register DCR. Am i missing something?

Can you outline in more detail what you exactly mean here? E.g., which 
specific steps do you think will be taken? (Who communicates with whom 
and what messages are being exchanged. You can draw this up as a message 
sequence chart if you want.)

> Can GDB handle these values on its own? If yes, then mapping these 
> registers will surely be advantageous.
> 
>  3.
> 
>     For all the other or1k debug registers, it is mentioned that the
>     “value is set by the resident debug software or by the development
>     interface.” This implies GDB will be handling these values and CDM
>     module will transfer those values to the actual debug registers over
>     debugging signals, right? If yes, then should I be concerned about
>     how GDB set those values?

yes. You don't need to be concerned exactly how GDB handles these 
values, since you're building a "transparent" interface". What data is 
being transferred through it isn't important at this point.

>  4. Mapping all the registers to 32 bit OSD register will be much
>     better. There will not be any issue in any read or write operation.
>     So, I will update the specification accordingly. That would mean I
>     have to extend
>     https://github.com/opensocdebug/osd-hw/blob/master/blocks/regaccess/common/osd_regaccess_layer.svto
>     32 bits.

Using 32 bit values makes things easier in the specification, but 
requires you to implement it. Actually not only in hardware, but you 
also need to double-check if the software supports it everywhere. 
Support exists in some parts of the code, but not in all of them AFAIK.

> 
> 
> Thanks
> - Shivam Aggarwal
> 
> On Sat, May 5, 2018 at 7:43 PM, SHIVAM AGGARWAL <shivam16195 at iiitd.ac.in 
> <mailto:shivam16195 at iiitd.ac.in>> wrote:
> 
>     Hi
> 
>     I have opened a PR: https://github.com/opensocdebug/osd-doc/pull/8
>     <https://github.com/opensocdebug/osd-doc/pull/8>
> 
>     Please take a look whenever you get some time.
> 
>     Thanks
>     *- Shivam Aggarwal*
> 
>     On Fri, May 4, 2018 at 2:21 AM, Philipp Wagner
>     <philipp.wagner at tum.de <mailto:philipp.wagner at tum.de>> wrote:
> 
>         Hi,
> 
>         Am 03.05.2018 um 22:26 schrieb SHIVAM AGGARWAL:
>         >     - Start working on a PR containing the specification for this module.
>         > 
>         > Currently I am working on the PR. So, I read the complete specification
>         > for all the other debug modules. I think specification of Memory Access
>         > Module (MAM)
>          >
>         <https://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/mam/index.html
>         <https://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/mam/index.html>> will
>         > be very handy for the implementation. We are supposed to create a Memory
>         > mapped interface just like the one used in MAM module. Debugging signals
>         > will be used for system interface. 
> 
>         The MAM is actually pretty special in a way that most of its
>         functionality is not register mapped but packaged in special
>         events. But
>         still the register mapped functionality
>         (http://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/mam/dbgregisters.html
>         <http://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/mam/dbgregisters.html>)
>         of the MAM (like any other debug module) can serve as a good
>         starting point.
> 
>         > I will share the complete specification as per my understanding by
>         > Friday night IST. 
>         > 
>         > Just one doubt, should I write the specification in .rst format or in
>         > Google docs? Which one will be more better?
> 
>         Take the rst of an existing debug module as starting point (i.e. the
>         structure, how to lay out the register mapping tables, etc.) and
>         modify
>         them to contain your specification text.
> 
>         Once you're happy with the text, open a PR for further discussion.
> 
>         Philipp
> 
> 
> 




More information about the OpenSoCDebug mailing list