OpenCores
Issue List
GDB 6.8 bug with real FPGA #58
Closed peterxiu opened this issue almost 15 years ago
peterxiu commented almost 15 years ago

My fpga system is the orp_soc implementation,and GDB 6.8 is patched,newest toolschain used.

There is some problem with I use gdb with remote jtag protocol (target jtag jtag://localhost:9999).

1)break problem: when only set one breakpoint, the GDB never stop running. when set more then one breakpoing,the GDB can stop after the first breakpoint(sometimes can stop at the first breakpoint). There is some mismatch between to orp_soc implement and the openrisc 1000 document.The DMR2:WGB bit start from bit:12 in spec ,compareing with the verilog implement begin at 13bit.

2)stepi problem: when stepi through branch instruction(l.jar...),the MCU go through the jump inst and execute the next instruction instead of jummping to the branch address.The stepi command appers to ignore the branch instructions.

    I found the same issue in forum about gdb with or1ksim,but the soultion is to modity the or1ksim.I think it is the problem with the GDB.

    I enable the log on JP1,and find that or32-gdb implement the stepi command by insert the l.trap instruction after the each instruction when stepping runnning,and the trapping cause cpu stalling,and then add new l.tarp ,add npc.(and then MCU execute the next instruction after jump command).Maybe the inserting after the branch inst when cause some delay slot problem?

    I think the  effective way to implment stepi is to set DMR1:ST. Use  hardware stepping support instead of software l.trap adding solution.After each instruciton running ,the hardware generate trap and  stall the cpu automaticlly.I have test this method with jp1 code,and my hardware stepping ok,when stepping in branch command ,the MCU can run into the jumpping address.  

    I test method:(use jp1 low level jtag read/write funciton)
    stall mcu
    load  20 instruciton in 0x100 including l.jar .
    enable execption
    set trap to stall MCU
    set ST bit in DMR2
    unstall MCU 20 times,
    read the NPC 
    the NPC address is right and the code funcion is right.
jeremybennett commented almost 15 years ago
<p> Hi Peter, </p> <p> The remote JTAG protocol is obsolete, with no work on it for eight years. It has never been tested with GDB 6.8. I copied the code from GDB 5.3, guessing at the changes that were necessary to support a far newer GDB. </p> <p> All new GDB implementations should use the GDB Remote Serial Protocol. The OpenRISC remote JTAG protocol will be dropped in the near future (probably the next GDB release). </p> <p> I strongly recommend you move to RSP and write a driver for that for JP1. My application note on RSP should help you with this: </p> <p> <a href="http://www.embecosm.com/download/ean4.html">www.embecosm.com/download/ean4.html</a> </p> <p> There is also an example for the ORSoC USB JTAG cable implemented by Julius Baxter. Check out or_debug_proxy from the OpenCores SVN. </p> <p> If you need this urgently, my company, Embecosm, can provide a RSP to JP1 program for ViaTech as a commercial service. Please contact me at <a href="mailto:jeremy.bennett@embecosm.com">jeremy.bennett@embecosm.com</a>. </p> <p> I am marking this bug as closed, since I do not anticipate the changes being implemented prior to the JTAG protocol being dropped. </p> <p> Jeremy </p> <p> -- <br /> Tel: +44 (1590) 610184<br /> Cell: +44 (7970) 676050<br /> SkypeID: jeremybennett<br /> Email: jeremy.bennett@embecosm.com<br /> Web: www.embecosm.com<br /> </p>
jeremybennett was assigned almost 15 years ago
jeremybennett closed this almost 15 years ago
peterxiu commented almost 15 years ago

Thanks for your reply. I have read the RSP aritical in your website.After implement S packet in RSP Server side,the stepi problem maybe overcome.It is seem that GDB use RSP protocol to move hardware platform relative code to RSP Server side that make gdb porting more easily.

But have you test the stepi implement of gdb 5.8 with JTAG interface?I think it may be also has problem.Because gdb seems to share the same strategy that use soft breakpoint instead of hardware stepping.

jeremybennett commented almost 15 years ago
<p> Hi Peter, </p> <p> That's the idea of using RSP. It makes porting easier and much more reliable. It also means upgrading to the next version of GDB is far quicker. </p> <p> If there is a hardware breakpoint available, the JTAG protocol interface will attempt to use it, otherwise it will use a software breakpoint. You can explicitly ask GDB to use a hardware breakpoint with "hbreak". </p> <p> The RSP implementation is slightly different. There are separate z/Z packets for software and hardware breakpoints. At present I have only implemented the software breakpoint functionality, but it would be easy to provide the hardware breakpoint, by reusing the code from the JTAG protocol interface. </p> <p> HTH, </p> <p> Jeremy </p> <p> -- <br /> Tel: +44 (1590) 610184<br /> Cell: +44 (7970) 676050<br /> SkypeID: jeremybennett<br /> Email: <a href="mailto:jeremy.bennett@embecosm.com">jeremy.bennett@embecosm.com</a><br /> Web: <a href="http://www.embecosm.com">www.embecosm.com</a> </p>

Assignee
jeremybennett
Labels
Bug