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

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