From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens-Christian Lache To: Fernando Nasser , crossgcc@sources.redhat.com, gdb@sources.redhat.com, insight@sources.redhat.com, newlib@sources.redhat.com Subject: Re: Debugging with ANGEL Date: Wed, 15 Nov 2000 10:12:00 -0000 Message-id: <00111519092700.13870@lab04> References: <00111514532502.01686@lab04> <3A12B912.3864E7BA@cygnus.com> X-SW-Source: 2000-q4/msg00227.html 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