This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Debugging with ANGEL


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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]