From carlos at codesourcery.com Wed Jun 1 14:38:50 2011 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 1 Jun 2011 10:38:50 -0400 Subject: [coldfire-gnu-discuss] GDB freeze when steping into a loop with P&E BDM In-Reply-To: <9C97D7A81BFEA849807B13E9160B5DEF0EAA946C@CERNXCHG21.cern.ch> References: <9C97D7A81BFEA849807B13E9160B5DEF0EAA63BF@CERNXCHG21.cern.ch>,<4DD6AB34.6080004@codesourcery.com> <9C97D7A81BFEA849807B13E9160B5DEF0EAA63DA@CERNXCHG21.cern.ch> <4DD6CD5E.5020108@codesourcery.com> <9C97D7A81BFEA849807B13E9160B5DEF0EAA946C@CERNXCHG21.cern.ch> Message-ID: <4DE64EFA.5020509@codesourcery.com> On 5/23/2011 5:52 AM, Stephane Franck Rey wrote: > Hi Carlos, > > Attached is a zip including my example project. > > I've debugged my example code using gdb command line and found the > same problem excluding then an IDE problem. Below are my tests > results details but to summarize here is what I've seen: > > 1. invoking gdb, setting breakpoints, running the program with > command 'continue' The program starts but doesn't stop on breakpoint, > I have to CTRL+C to stop it and could see then it is "halted" on line > 57 (for ...). Displaying data 'i' shows GDB has reached an > intermediate value loop iterations before halting. (several tests : > i=23468, 37406, 24028, ...) When continuing again, then it stops to > the first breakpoint line 66 correctly > > 2. When stopped on 1st breakpoint on line 66, I seize 'next' command > and can stop on each line until line 68 (2nd breakpoint : for ...). > Then from line 68 the program "halts" again and GDB seems to be > crashed this time I can't CTRL+C. I have to kill GDB and restart it. > > 3. An other test is made when reaching breakpoint on line 68. I step > by assembly instruction and it works perfectly. If after several > steps (i=2 or 3) I 'continue' the program, then it stops correctly to > the line 66 showing that the program works and reached the 2nd > forever main loop iteration. Thank you for the accurate test case, unfortunately I don't recognize this failure as anything we've fixed recently. I've submitted an internal ticket for our team to review this issue. We are always interested in fixing problems, but as a Lite edition user I can't guarantee an immediate fix. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos at codesourcery.com +1 (613) 963 1026 From carlos at codesourcery.com Wed Jun 1 15:52:43 2011 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 1 Jun 2011 11:52:43 -0400 Subject: [coldfire-gnu-discuss] GDB freeze when steping into a loop with P&E BDM In-Reply-To: <9C97D7A81BFEA849807B13E9160B5DEF0EAA946C@CERNXCHG21.cern.ch> References: <9C97D7A81BFEA849807B13E9160B5DEF0EAA63BF@CERNXCHG21.cern.ch>,<4DD6AB34.6080004@codesourcery.com> <9C97D7A81BFEA849807B13E9160B5DEF0EAA63DA@CERNXCHG21.cern.ch> <4DD6CD5E.5020108@codesourcery.com> <9C97D7A81BFEA849807B13E9160B5DEF0EAA946C@CERNXCHG21.cern.ch> Message-ID: <4DE6604B.6030802@codesourcery.com> On 5/23/2011 5:52 AM, Stephane Franck Rey wrote: > Then defined the target connection : > > ****************************************************************** > (gdb) target remote | m68k-elf-sprite pe://USBMultilink m51ac128cevb > Remote debugging using | m68k-elf-sprite pe://USBMultilink m51ac128cevb > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-12 Rev C (PE5516 > 318)) > m68k-elf-sprite: Target reset > 0x00000000 in _ftext () > ****************************************************************** > > > I've set some breakpoints lines 66 and line 68 : > > ****************************************************************** > (gdb) info break > Num Type Disp Enb Address What > 1 breakpoint keep y 0x00000626 in main at ../main.c:66 > 2 breakpoint keep y 0x0000065a in main at ../main.c:68 > ****************************************************************** > > > And ran the program : > > ****************************************************************** > (gdb) c > Continuing. > Note: automatically using hardware breakpoints for read-only addresses. > ****************************************************************** > > > After a while nothing is happening I press CTRL+C : If you wait a *very* long time does the program run to completion? For example if you wait several hours does it complete? Is it simply that the debug interface is being incredibly slow? Could you confirm that please? > ****************************************************************** > Program received signal SIGINT, Interrupt. > 0x00000620 in main () at ../main.c:57 > 57 for (i=1; i<50000; i++) > (gdb) display i > 1: i = 24028 > ****************************************************************** > Several tests have shown it halts for random value of I (24028, 37406, ...) > > Then I continue the execution until it stops definitely on line 68 : > > ****************************************************************** > (gdb) c > Continuing. > > Breakpoint 1, main () at ../main.c:66 > 66 PTFD&= ~PTFD_PTFD0_MASK;; > 1: i = 50000 > (gdb) next > 67 PTFD |= PTFD_PTFD1_MASK ;; > 1: i = 50000 > (gdb) next > > Breakpoint 2, main () at ../main.c:68 > 68 for (i=1; i<40000; i++){asm ("nop");}; > 1: i = 50000 > (gdb) > ^C Another question, did your CTRL+C come *before* or *after* Breakpoint 2 was hit? If the program isn't running CTRL+C won't do anything. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos at codesourcery.com +1 (613) 963 1026 From stephane.franck.rey at cern.ch Wed Jun 1 16:05:54 2011 From: stephane.franck.rey at cern.ch (Stephane Franck Rey) Date: Wed, 1 Jun 2011 16:05:54 +0000 Subject: [coldfire-gnu-discuss] GDB freeze when steping into a loop with P&E BDM Message-ID: <9C97D7A81BFEA849807B13E9160B5DEF0EAAAC70@CERNXCHG21.cern.ch> Well, usually the debugging is immediate and I do not notice latency when continuing between the 1st and 2nd breakpoint. When it seems to be lost somewhere before reaching the 1st BP, then I've tried to leave the debugger running several minutes (maybe 5-6mn) before assuming then that something was wrong. I will try to leave it several hours to see what happens... Regarding your question about CTRL+C : When starting the first time the program, nothing seems happening before reaching 1st BP, So I CTRL+C which halts the debug in the 1st loop, then I continue and it reach BP#2 immediately. If continuing again, then it crashs or seems to crash. I hope I've been clear in my explanations. Let me know if not Cheers Stephane -----Original Message----- From: Carlos O'Donell [mailto:carlos at codesourcery.com] Sent: mercredi 1 juin 2011 17:53 To: Stephane Franck Rey Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] GDB freeze when steping into a loop with P&E BDM On 5/23/2011 5:52 AM, Stephane Franck Rey wrote: > Then defined the target connection : > > ****************************************************************** > (gdb) target remote | m68k-elf-sprite pe://USBMultilink m51ac128cevb > Remote debugging using | m68k-elf-sprite pe://USBMultilink m51ac128cevb > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-12 Rev C (PE5516 > 318)) > m68k-elf-sprite: Target reset > 0x00000000 in _ftext () > ****************************************************************** > > > I've set some breakpoints lines 66 and line 68 : > > ****************************************************************** > (gdb) info break > Num Type Disp Enb Address What > 1 breakpoint keep y 0x00000626 in main at ../main.c:66 > 2 breakpoint keep y 0x0000065a in main at ../main.c:68 > ****************************************************************** > > > And ran the program : > > ****************************************************************** > (gdb) c > Continuing. > Note: automatically using hardware breakpoints for read-only addresses. > ****************************************************************** > > > After a while nothing is happening I press CTRL+C : If you wait a *very* long time does the program run to completion? For example if you wait several hours does it complete? Is it simply that the debug interface is being incredibly slow? Could you confirm that please? > ****************************************************************** > Program received signal SIGINT, Interrupt. > 0x00000620 in main () at ../main.c:57 > 57 for (i=1; i<50000; i++) > (gdb) display i > 1: i = 24028 > ****************************************************************** > Several tests have shown it halts for random value of I (24028, 37406, ...) > > Then I continue the execution until it stops definitely on line 68 : > > ****************************************************************** > (gdb) c > Continuing. > > Breakpoint 1, main () at ../main.c:66 > 66 PTFD&= ~PTFD_PTFD0_MASK;; > 1: i = 50000 > (gdb) next > 67 PTFD |= PTFD_PTFD1_MASK ;; > 1: i = 50000 > (gdb) next > > Breakpoint 2, main () at ../main.c:68 > 68 for (i=1; i<40000; i++){asm ("nop");}; > 1: i = 50000 > (gdb) > ^C Another question, did your CTRL+C come *before* or *after* Breakpoint 2 was hit? If the program isn't running CTRL+C won't do anything. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos at codesourcery.com +1 (613) 963 1026