Re: Debugging with ANGEL

Re: Debugging with ANGEL

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

Hi! I still haven´t fixed the problem yet, but I can avoid the deadlock now.
It appears on the second swi instruction in
"initialise_monitor_handles" @ 0xZZZZ8fd0 (where 0xZZZZ0000) is the
adress, where my program is linked to) in 
 newlib-1.8.2/newlib/libc/sys/arm/syscalls.c

After the swi, the pc jumps back to the beginning of the instruction. This 
would happen forever, if I would´t set the pc to the next instruction.
The variable monitor_stdin is set to 3,  monitor_stout and monitor_stderr
are set to 33558724 a few instr. later. If I set them to 0 by hand, I can use 
->{} (Continue) to get to the breakpoint at main.

What can I do to make stdin, stdout and stderr make work correctly?

(To which mailing list does this message belong?)

Am Mit, 14 Nov 2000 schrieben Sie:
> I'm trying to debug an arm-elf program on a ARM7TDMI based
> testboard with insight-5.0. I can download my own program,
> but when debugging, I can not reach the breakpoint at main.
> 
> I receive the following message:
> 
> ! Program received signal SIGTRAP, Trace/breakpoint trap
> 
> -> syscalls.c Line 65 
> 59	#ifdef ARM_RDI_MONITOR
> 60	
> 61	static inline int
> 62	do_AngelSWI (int reason, void * arg)
> 63	{
> 64	  int value;
> 65	  asm volatile ("mov r0, %1; mov r1, %2; swi %a3; mov %0, r0"
> 66	       : "=r" (value) /* Outputs */
> 67	       : "r" (reason), "r" (arg), "i" (AngelSWI) /* Inputs */
> 68	       : "r0", "r1", "lr"
> 69			/* Clobbers r0 and r1, and lr if in supervisor mode
> 70	*/);   return value;
> 71	}
> 72	#endif /* ARM_RDI_MONITOR */
> 
> 
> Stack: initialise_monitor_handles
> PC: 0x02018cb0
> 
> (newlib-1.8.2/newlib/libc/sys/arm/syscalls.c)
> 
> I can set breakpoints before the error occurs and step next. It looks like 
> after every instruction there occurs a SWI (to do the communication with me I
> guess). The line 65 in syscalls.c is executed quite often, but finally I loose
> the connection and the board is deadlocked. 
> 
> When I set a breakpoint at 
>  void initialise_monitor_handles(void)
> the debugger shows an other strange behavior: It exectutes line 103-105:
>   block[0] = (int) ":tt";
>   block[2] = 3;     /* length of filename */
>   block[1] = 0;     /* mode "r" */
> and than it jumps back to line 103. It executes the lines one more
> time, than executes line 108-110:
>   block[0] = (int) ":tt";
>   block[2] = 3;     /* length of filename */
>   block[1] = 4;     /* mode "w" */
> and jumps back to line 106:
>   monitor_stdin = do_AngelSWI (AngelSWI_Reason_Open, block);
> then it jumps to line 111:
>   monitor_stdout = monitor_stderr = do_AngelSWI (AngelSWI_Reason_Open, block);
> back to 106, line 65 and ciao bella...
> 
> Any hints? 
> 
> Jens-Christian
> 
> 
> Jens-Christian Lache
> Technische Universitaet Hamburg-Harburg
> www.tu-harburg.de/~sejl1601
> Mail:
> lache@tu-harburg.de
> lache@ngi.de
> Tel.: 
> +0491759610756
>

Re: Debugging with ANGEL

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6118 bytes --]

Thank you! It´s working fine now. I tested just stdout with printf(), and it
worked fine.  Puhh! It took me three looong days to get the gnu-tool-chain
say "Hello world" on my ARM processor. Hard work!

I have some smaller questions:
* How can I make insight remember my target settings?
   (ARM Angel/serial, baud rate,...)
   I tried to use a faster communication to the board with

	stty 38400 < /dev/ttyS1
	and in target settings baud rate: 38400
   Didn´t work! ?
* I think I will have to replace the Angel interrupt routine with my own
   and forward calls from the serial link to the old one. Ok, I will read
    through all the doc about Angel in ARM DUI 0040D Chapter 13,
    everything else wich will be necessary.
     But can I come back, when I`m stuck too deeply? :-)
* An other stupid question: What time difference is between Hamburg
  and Toronto (plus or minus?)  And what difference between Toronto
  and Silicon Valley?

Jens-Christian, Hamburg




 Am Mit, 15 Nov 2000 schrieben Sie:
> I took the insight list out.  That is for the GUI.
> 
> I don't know if this is the cause of your problem, but the code for 
> do_AngelSWI is outdated.  The correct one is below (a bug I found last year).
> Please make the changes and rebuild your newlibs.
> 
> I will check later if this is not in the current sources.
> 
> static inline int
> do_AngelSWI (int reason, void * arg)
> {
>   int value;
>   asm volatile ("mov r0, %1; mov r1, %2; swi %a3; mov %0, r0"
>        : "=r" (value) /* Outputs */
>        : "r" (reason), "r" (arg), "i" (AngelSWI) /* Inputs */
>        : "r0", "r1", "r2", "r3", "ip", "lr", "memory"
>                 /* Clobbers r0 and r1, and lr if in supervisor mode */);
>                   /* Accordingly to page 13-77 of ARM DUI 0040D other registers
>                      can also be clobbered.  Some memory positions may also be
>                      changed by a system call, so they should not be kept in
>                      registers. Note: we are assuming the manual is right and
>                      Angel is respecting the APCS */
>   return value;
> }
> 
> 
> I fixed yet another bug last year, with help from Jeff, that prevented program
> output to show up (it did not cause any lockups or crashes though).
> 
> If after making the correction above you still have problems with stdout and
> stderr let me know and I will dig that patch for you (I will check if that one
> made to the main repository later today).
> 
> Good luck!
> 
> Fernando
> 
> 
>  
> 
> Jens-Christian Lache wrote:
> > 
> > Hi! I still haven´t fixed the problem yet, but I can avoid the deadlock now.
> > It appears on the second swi instruction in
> > "initialise_monitor_handles" @ 0xZZZZ8fd0 (where 0xZZZZ0000) is the
> > adress, where my program is linked to) in
> >  newlib-1.8.2/newlib/libc/sys/arm/syscalls.c
> > 
> > After the swi, the pc jumps back to the beginning of the instruction. This
> > would happen forever, if I would´t set the pc to the next instruction.
> > The variable monitor_stdin is set to 3,  monitor_stout and monitor_stderr
> > are set to 33558724 a few instr. later. If I set them to 0 by hand, I can use
> > ->{} (Continue) to get to the breakpoint at main.
> > 
> > What can I do to make stdin, stdout and stderr make work correctly?
> > 
> > (To which mailing list does this message belong?)
> > 
> > Am Mit, 14 Nov 2000 schrieben Sie:
> > > I'm trying to debug an arm-elf program on a ARM7TDMI based
> > > testboard with insight-5.0. I can download my own program,
> > > but when debugging, I can not reach the breakpoint at main.
> > >
> > > I receive the following message:
> > >
> > > ! Program received signal SIGTRAP, Trace/breakpoint trap
> > >
> > > -> syscalls.c Line 65
> > > 59    #ifdef ARM_RDI_MONITOR
> > > 60
> > > 61    static inline int
> > > 62    do_AngelSWI (int reason, void * arg)
> > > 63    {
> > > 64      int value;
> > > 65      asm volatile ("mov r0, %1; mov r1, %2; swi %a3; mov %0, r0"
> > > 66           : "=r" (value) /* Outputs */
> > > 67           : "r" (reason), "r" (arg), "i" (AngelSWI) /* Inputs */
> > > 68           : "r0", "r1", "lr"
> > > 69                    /* Clobbers r0 and r1, and lr if in supervisor mode
> > > 70    */);   return value;
> > > 71    }
> > > 72    #endif /* ARM_RDI_MONITOR */
> > >
> > >
> > > Stack: initialise_monitor_handles
> > > PC: 0x02018cb0
> > >
> > > (newlib-1.8.2/newlib/libc/sys/arm/syscalls.c)
> > >
> > > I can set breakpoints before the error occurs and step next. It looks like
> > > after every instruction there occurs a SWI (to do the communication with me I
> > > guess). The line 65 in syscalls.c is executed quite often, but finally I loose
> > > the connection and the board is deadlocked.
> > >
> > > When I set a breakpoint at
> > >  void initialise_monitor_handles(void)
> > > the debugger shows an other strange behavior: It exectutes line 103-105:
> > >   block[0] = (int) ":tt";
> > >   block[2] = 3;     /* length of filename */
> > >   block[1] = 0;     /* mode "r" */
> > > and than it jumps back to line 103. It executes the lines one more
> > > time, than executes line 108-110:
> > >   block[0] = (int) ":tt";
> > >   block[2] = 3;     /* length of filename */
> > >   block[1] = 4;     /* mode "w" */
> > > and jumps back to line 106:
> > >   monitor_stdin = do_AngelSWI (AngelSWI_Reason_Open, block);
> > > then it jumps to line 111:
> > >   monitor_stdout = monitor_stderr = do_AngelSWI (AngelSWI_Reason_Open, block);
> > > back to 106, line 65 and ciao bella...
> > >
> > > Any hints?
> > >
> > > Jens-Christian
> > >
> > >
> > > Jens-Christian Lache
> > > Technische Universitaet Hamburg-Harburg
> > > www.tu-harburg.de/~sejl1601
> > > Mail:
> > > lache@tu-harburg.de
> > > lache@ngi.de
> > > Tel.:
> > > +0491759610756
> > >
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

Re: Debugging with ANGEL

[Fernando Nasser]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5027 bytes --]

It is in the current sources (out of cvs).  gdb 5.0 release didn't have it, it seems.

Jens, maybe you should get yourself the gdb sources out of cvs while gdb 5.1 is
not released.  This way you get all the bug fixes that were made for ARM and Insight
after 5.0.

Fernando


Fernando Nasser wrote:
> 
> I took the insight list out.  That is for the GUI.
> 
> I don't know if this is the cause of your problem, but the code for
> do_AngelSWI is outdated.  The correct one is below (a bug I found last year).
> Please make the changes and rebuild your newlibs.
> 
> I will check later if this is not in the current sources.
> 
> static inline int
> do_AngelSWI (int reason, void * arg)
> {
>   int value;
>   asm volatile ("mov r0, %1; mov r1, %2; swi %a3; mov %0, r0"
>        : "=r" (value) /* Outputs */
>        : "r" (reason), "r" (arg), "i" (AngelSWI) /* Inputs */
>        : "r0", "r1", "r2", "r3", "ip", "lr", "memory"
>                 /* Clobbers r0 and r1, and lr if in supervisor mode */);
>                   /* Accordingly to page 13-77 of ARM DUI 0040D other registers
>                      can also be clobbered.  Some memory positions may also be
>                      changed by a system call, so they should not be kept in
>                      registers. Note: we are assuming the manual is right and
>                      Angel is respecting the APCS */
>   return value;
> }
> 
> I fixed yet another bug last year, with help from Jeff, that prevented program
> output to show up (it did not cause any lockups or crashes though).
> 
> If after making the correction above you still have problems with stdout and
> stderr let me know and I will dig that patch for you (I will check if that one
> made to the main repository later today).
> 
> Good luck!
> 
> Fernando
> 
> 
> 
> Jens-Christian Lache wrote:
> >
> > Hi! I still haven´t fixed the problem yet, but I can avoid the deadlock now.
> > It appears on the second swi instruction in
> > "initialise_monitor_handles" @ 0xZZZZ8fd0 (where 0xZZZZ0000) is the
> > adress, where my program is linked to) in
> >  newlib-1.8.2/newlib/libc/sys/arm/syscalls.c
> >
> > After the swi, the pc jumps back to the beginning of the instruction. This
> > would happen forever, if I would´t set the pc to the next instruction.
> > The variable monitor_stdin is set to 3,  monitor_stout and monitor_stderr
> > are set to 33558724 a few instr. later. If I set them to 0 by hand, I can use
> > ->{} (Continue) to get to the breakpoint at main.
> >
> > What can I do to make stdin, stdout and stderr make work correctly?
> >
> > (To which mailing list does this message belong?)
> >
> > Am Mit, 14 Nov 2000 schrieben Sie:
> > > I'm trying to debug an arm-elf program on a ARM7TDMI based
> > > testboard with insight-5.0. I can download my own program,
> > > but when debugging, I can not reach the breakpoint at main.
> > >
> > > I receive the following message:
> > >
> > > ! Program received signal SIGTRAP, Trace/breakpoint trap
> > >
> > > -> syscalls.c Line 65
> > > 59    #ifdef ARM_RDI_MONITOR
> > > 60
> > > 61    static inline int
> > > 62    do_AngelSWI (int reason, void * arg)
> > > 63    {
> > > 64      int value;
> > > 65      asm volatile ("mov r0, %1; mov r1, %2; swi %a3; mov %0, r0"
> > > 66           : "=r" (value) /* Outputs */
> > > 67           : "r" (reason), "r" (arg), "i" (AngelSWI) /* Inputs */
> > > 68           : "r0", "r1", "lr"
> > > 69                    /* Clobbers r0 and r1, and lr if in supervisor mode
> > > 70    */);   return value;
> > > 71    }
> > > 72    #endif /* ARM_RDI_MONITOR */
> > >
> > >
> > > Stack: initialise_monitor_handles
> > > PC: 0x02018cb0
> > >
> > > (newlib-1.8.2/newlib/libc/sys/arm/syscalls.c)
> > >
> > > I can set breakpoints before the error occurs and step next. It looks like
> > > after every instruction there occurs a SWI (to do the communication with me I
> > > guess). The line 65 in syscalls.c is executed quite often, but finally I loose
> > > the connection and the board is deadlocked.
> > >
> > > When I set a breakpoint at
> > >  void initialise_monitor_handles(void)
> > > the debugger shows an other strange behavior: It exectutes line 103-105:
> > >   block[0] = (int) ":tt";
> > >   block[2] = 3;     /* length of filename */
> > >   block[1] = 0;     /* mode "r" */
> > > and than it jumps back to line 103. It executes the lines one more
> > > time, than executes line 108-110:
> > >   block[0] = (int) ":tt";
> > >   block[2] = 3;     /* length of filename */
> > >   block[1] = 4;     /* mode "w" */
> > > and jumps back to line 106:
> > >   monitor_stdin = do_AngelSWI (AngelSWI_Reason_Open, block);
> > > then it jumps to line 111:
> > >   monitor_stdout = monitor_stderr = do_AngelSWI (AngelSWI_Reason_Open, block);
> > > back to 106, line 65 and ciao bella...
> > >
> > > Any hints?
> > >
> > > Jens-Christian
> > >
> > >



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Debugging with ANGEL

[Jens-Christian Lache]

I'm trying to debug an arm-elf program on a ARM7TDMI based
testboard with insight-5.0. I can download my own program,
but when debugging, I can not reach the breakpoint at main.

I receive the following message:

! Program received signal SIGTRAP, Trace/breakpoint trap

-> syscalls.c Line 65 
59	#ifdef ARM_RDI_MONITOR
60	
61	static inline int
62	do_AngelSWI (int reason, void * arg)
63	{
64	  int value;
65	  asm volatile ("mov r0, %1; mov r1, %2; swi %a3; mov %0, r0"
66	       : "=r" (value) /* Outputs */
67	       : "r" (reason), "r" (arg), "i" (AngelSWI) /* Inputs */
68	       : "r0", "r1", "lr"
69			/* Clobbers r0 and r1, and lr if in supervisor mode
70	*/);   return value;
71	}
72	#endif /* ARM_RDI_MONITOR */


Stack: initialise_monitor_handles
PC: 0x02018cb0

(newlib-1.8.2/newlib/libc/sys/arm/syscalls.c)

I can set breakpoints before the error occurs and step next. It looks like 
after every instruction there occurs a SWI (to do the communication with me I
guess). The line 65 in syscalls.c is executed quite often, but finally I loose
the connection and the board is deadlocked. 

When I set a breakpoint at 
 void initialise_monitor_handles(void)
the debugger shows an other strange behavior: It exectutes line 103-105:
  block[0] = (int) ":tt";
  block[2] = 3;     /* length of filename */
  block[1] = 0;     /* mode "r" */
and than it jumps back to line 103. It executes the lines one more
time, than executes line 108-110:
  block[0] = (int) ":tt";
  block[2] = 3;     /* length of filename */
  block[1] = 4;     /* mode "w" */
and jumps back to line 106:
  monitor_stdin = do_AngelSWI (AngelSWI_Reason_Open, block);
then it jumps to line 111:
  monitor_stdout = monitor_stderr = do_AngelSWI (AngelSWI_Reason_Open, block);
back to 106, line 65 and ciao bella...

Any hints? 

Jens-Christian


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.: 
+0491759610756