Debugging with ANGEL

Fernando Nasser fnasser@cygnus.com
Wed Nov 15 08:26:00 GMT 2000


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

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com



More information about the crossgcc mailing list