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

Philipp Wagner philipp.wagner at tum.de
Mon May 7 14:50:45 CEST 2018


On 05/07/2018 02:46 PM, SHIVAM AGGARWAL wrote:
> 
> Hi,
> I believe now I have a firm understanding of CDM module. Please validate 
> the details I mentioned on the basis of my understanding. It will be 
> relatively easy to work on the specification after this point. *
> 
> *
> On Mon, May 7, 2018 at 12:40 PM, Philipp Wagner <philipp.wagner at tum.de 
> <mailto:philipp.wagner at tum.de>> wrote:
> 
>     Hi Shivam,
> 
>     I've forwarded this to the opensocdebug mailing list, please keep
>     all technical discussion there.
> 
> 
> Noted.
> 
> 
>     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.
> 
> 
> Thanks for the clarification.
> 
> 
>         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
>         <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.
> 
> 
> So, I will go with the two 16 bit registers specification. For write 
> operation, we will have an additional update register which must be 
> written to make sure the data is written correctly. A read operation 
> will take place only after a breakpoint is hit. This would mean that the 
> core is stopped and the value of the register should not change. So, 
> there will not be any trouble with read operation.
> 
> Let me sum up the description of CDM module. In CDM module, each or1k 
> debug registers is mapped into two 16 bit wide OSD register. Now,  I can 
> set breakpoints in my program using GDB. Every time, a breakpoint is to 
> be set up, GDB asks for register access. This is accomplished using 
> osd_regaccess_layer. Now, the address of the breakpoint is loaded in the 
> module debug registers. This value is transferred to or1k debug 
> registers over debugging signals. The program is executed. Once a 
> breakpoint is hit, an event is generated by the CDM module. The CPU is 
> stalled. The control is passed to the GDB. Debugging of the program 
> takes place.
> 
> CDM module will receive the information from GDB and transfer the values 
> to or1k and vice-versa. The module is not responsible for setting up the 
> values of debug registers or determining when/how a program counter 
> matches with the breakpoint address. All these issues will be handled 
> internally. Now, while generating events, the only event in CDM module 
> will be "BREAKPOINT HIT". I understand that as in the case of CTM module 
> <http://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/ctm/datainterface.html>, 
> we will have an event packet "Breakpoint hit" to notify the debugger 
> when a breakpoint is hit. The content (payload word) of this debug 
> packet could be the number of which breakpoint is reached. Should we 
> have any other detail in the event debug packet?

That should be all data that's needed, if not, there's no harm in 
modifying the specs.

Philipp


More information about the OpenSoCDebug mailing list