* [ECOS] printf does not work in user mode on Arm E7T @ 2003-03-26 8:12 Pierre Habraken 2003-03-26 8:26 ` Andrew Lunn 0 siblings, 1 reply; 10+ messages in thread From: Pierre Habraken @ 2003-03-26 8:12 UTC (permalink / raw) To: newlib; +Cc: ecos-discuss Hello, For demonstration purpose, I have inserted printf calls in a program running on an Arm Evaluator 7T (controlled by gdb as a remote target). The program is linked against newlib libc but and it uses redboot syscalls (redboot.specs). Some parts of the program runs in svc mode (cpsr = 0x13), other parts run in usr mode (cpsr = 0x10), each mode using its own stack. When printf is called with the processor being in svc mode, the corresponding output is displayed in the gdb console and the program continues then with its execution. When printf is called with the processor being in usr mode, nothing is displayed in the gdb console and the program hangs or raises a BUS ERROR. Could someone explain me what printf would not work in user mode ? Thanks in advance for any help. Pierre -- ________________________________________________________________________ Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex ________________________________________________________________________ -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-26 8:12 [ECOS] printf does not work in user mode on Arm E7T Pierre Habraken @ 2003-03-26 8:26 ` Andrew Lunn 2003-03-26 11:59 ` Thomas BINDER 2003-03-26 12:56 ` Pierre Habraken 0 siblings, 2 replies; 10+ messages in thread From: Andrew Lunn @ 2003-03-26 8:26 UTC (permalink / raw) To: Pierre Habraken; +Cc: newlib, ecos-discuss This is not an area of eCos i know, so this is more of a guess. How is your MMU setup? Maybe in user mode the MMU is stopping access to the memory where the serial port is, or some other critical region of memory. What is it trying to do when you get a BUS error? That may give you a clue. Andrew On Wed, Mar 26, 2003 at 09:19:51AM +0100, Pierre Habraken wrote: > Hello, > > For demonstration purpose, I have inserted printf calls in a program > running on an Arm Evaluator 7T (controlled by gdb as a remote target). > The program is linked against newlib libc but and it uses redboot > syscalls (redboot.specs). > Some parts of the program runs in svc mode (cpsr = 0x13), other parts > run in usr mode (cpsr = 0x10), each mode using its own stack. > When printf is called with the processor being in svc mode, the > corresponding output is displayed in the gdb console and the program > continues then with its execution. > When printf is called with the processor being in usr mode, nothing is > displayed in the gdb console and the program hangs or raises a BUS > ERROR. > Could someone explain me what printf would not work in user mode ? > > Thanks in advance for any help. > > Pierre > -- > ________________________________________________________________________ > Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr > Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 > IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex > ________________________________________________________________________ > > -- > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos > and search the list archive: http://sources.redhat.com/ml/ecos-discuss > -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-26 8:26 ` Andrew Lunn @ 2003-03-26 11:59 ` Thomas BINDER 2003-03-26 16:49 ` Jonathan Larmour 2003-03-26 12:56 ` Pierre Habraken 1 sibling, 1 reply; 10+ messages in thread From: Thomas BINDER @ 2003-03-26 11:59 UTC (permalink / raw) To: Andrew Lunn; +Cc: Pierre Habraken, newlib, ecos-discuss Hi! My guess is that you have thread safety (option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS) enabled, in which case printf, sprintf, fprintf use a Cyg_Mutex object for synchronization (via Cyg_StdioStream, c.f. http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00194.html). Have you set up your MMU such that access to kernel objects is not allowed in user mode? best regards, Tom Andrew Lunn wrote: > > This is not an area of eCos i know, so this is more of a guess. > > How is your MMU setup? Maybe in user mode the MMU is stopping access > to the memory where the serial port is, or some other critical region > of memory. What is it trying to do when you get a BUS error? That may > give you a clue. > > Andrew > > On Wed, Mar 26, 2003 at 09:19:51AM +0100, Pierre Habraken wrote: > > Hello, > > > > For demonstration purpose, I have inserted printf calls in a program > > running on an Arm Evaluator 7T (controlled by gdb as a remote target). > > The program is linked against newlib libc but and it uses redboot > > syscalls (redboot.specs). > > Some parts of the program runs in svc mode (cpsr = 0x13), other parts > > run in usr mode (cpsr = 0x10), each mode using its own stack. > > When printf is called with the processor being in svc mode, the > > corresponding output is displayed in the gdb console and the program > > continues then with its execution. > > When printf is called with the processor being in usr mode, nothing is > > displayed in the gdb console and the program hangs or raises a BUS > > ERROR. > > Could someone explain me what printf would not work in user mode ? > > > > Thanks in advance for any help. > > > > Pierre > > -- > > ________________________________________________________________________ -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-26 11:59 ` Thomas BINDER @ 2003-03-26 16:49 ` Jonathan Larmour 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Larmour @ 2003-03-26 16:49 UTC (permalink / raw) To: Thomas BINDER; +Cc: Andrew Lunn, Pierre Habraken, newlib, ecos-discuss Thomas BINDER wrote: > Hi! > > My guess is that you have thread safety (option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS) enabled, in which case printf, sprintf, fprintf use a Cyg_Mutex object for synchronization (via Cyg_StdioStream, c.f. http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00194.html). Have you set up your MMU such that access to kernel objects is not allowed in user mode? He said he was using newlib libc, not eCos libc. This isn't an eCos application - the relevant bit is the use of RedBoot only. Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts --[ "You can complain because roses have thorns, or you ]-- --[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-26 8:26 ` Andrew Lunn 2003-03-26 11:59 ` Thomas BINDER @ 2003-03-26 12:56 ` Pierre Habraken 2003-03-26 16:54 ` Jonathan Larmour 1 sibling, 1 reply; 10+ messages in thread From: Pierre Habraken @ 2003-03-26 12:56 UTC (permalink / raw) To: Andrew Lunn; +Cc: newlib, ecos-discuss Andrew Lunn wrote: > > This is not an area of eCos i know, so this is more of a guess. > > How is your MMU setup? Maybe in user mode the MMU is stopping access > to the memory where the serial port is, or some other critical region > of memory. The Samsung processor on Evaluator 7T board does not have a MMU. > What is it trying to do when you get a BUS error? That may > give you a clue. What is strange is that I can't step into the printf subroutine: gdb hangs as soon as I have typed the command stepi. Actually, it seems that it is the 'branch to subroutine' (Arm BL) instruction which hangs when executed in user mode: I wrote a small C program the main function of which merely switches to usr mode and then call a dummy subprogram, and could observe the same behavior, ie the BL instruction hangs. I fear that the problem is related neither to printf nor to newlib or redboot but to the Arm (Samsung implementation) processor... Pierre > On Wed, Mar 26, 2003 at 09:19:51AM +0100, Pierre Habraken wrote: > > Hello, > > > > For demonstration purpose, I have inserted printf calls in a program > > running on an Arm Evaluator 7T (controlled by gdb as a remote target). > > The program is linked against newlib libc but and it uses redboot > > syscalls (redboot.specs). > > Some parts of the program runs in svc mode (cpsr = 0x13), other parts > > run in usr mode (cpsr = 0x10), each mode using its own stack. > > When printf is called with the processor being in svc mode, the > > corresponding output is displayed in the gdb console and the program > > continues then with its execution. > > When printf is called with the processor being in usr mode, nothing is > > displayed in the gdb console and the program hangs or raises a BUS > > ERROR. > > Could someone explain me what printf would not work in user mode ? > > > > Thanks in advance for any help. > > > > Pierre > > -- > > ________________________________________________________________________ > > Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr > > Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 > > IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex > > ________________________________________________________________________ > > > > -- > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss > > -- ________________________________________________________________________ Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex ________________________________________________________________________ -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-26 12:56 ` Pierre Habraken @ 2003-03-26 16:54 ` Jonathan Larmour 2003-03-27 2:04 ` Pierre Habraken 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Larmour @ 2003-03-26 16:54 UTC (permalink / raw) To: Pierre Habraken; +Cc: Andrew Lunn, newlib, ecos-discuss Pierre Habraken wrote: > What is strange is that I can't step into the printf subroutine: gdb > hangs as soon as I have typed the command stepi. It's not the first time I've had GDB problems with functions with variadic arguments. Try and set a breakpoint _inside_ printf by hand before you've stepped into it (e.g. set a breakpoint on some function that printf calls). > Actually, it seems that it is the 'branch to subroutine' (Arm BL) > instruction which hangs when executed in user mode: I wrote a small C > program the main function of which merely switches to usr mode and then > call a dummy subprogram, and could observe the same behavior, ie the BL > instruction hangs. > I fear that the problem is related neither to printf nor to newlib or > redboot but to the Arm (Samsung implementation) processor... Theoretically it could be RedBoot since it's up to RedBoot to set the next breakpoint to implement the single stepping, although that functionality itself is known to work fine elsewhere. It could also be some problem with RedBoot's ability to restore state back to user mode, although it's not clear why it would work for other instructions, but not prior to a BL. What age is this RedBoot? There were some significant patches from Mark Salter in this area a while back - April 2002. A hardware problem is always possible, but seems improbable really. Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts --[ "You can complain because roses have thorns, or you ]-- --[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-26 16:54 ` Jonathan Larmour @ 2003-03-27 2:04 ` Pierre Habraken 2003-03-31 13:11 ` Pierre Habraken 0 siblings, 1 reply; 10+ messages in thread From: Pierre Habraken @ 2003-03-27 2:04 UTC (permalink / raw) To: Jonathan Larmour; +Cc: newlib, ecos-discuss Jonathan Larmour wrote: > [...] > > Actually, it seems that it is the 'branch to subroutine' (Arm BL) > > instruction which hangs when executed in user mode: I wrote a > > small C program the main function of which merely switches to > > usr mode and then call a dummy subprogram, and could observe the > > same behavior, ie the BL instruction hangs. > > I fear that the problem is related neither to printf nor to newlib > > or redboot but to the Arm (Samsung implementation) processor... > > Theoretically it could be RedBoot since it's up to RedBoot to set the > next breakpoint to implement the single stepping, although that > functionality itself is known to work fine elsewhere. It could also be > some problem with RedBoot's ability to restore state back to user > mode, although it's not clear why it would work for other > instructions, but not prior to a BL. What age is this RedBoot? > There were some significant patches from Mark Salter in this area > a while back - April 2002. I re-built Redboot from CVS sources on last March 3rd. I attach below the test program I mentioned in my previous message. > A hardware problem is always possible, but seems improbable really. I agree. BTW, both programs (the one with printf's and the test program) work fine and behave as expected when compiled/linked without Redboot support and run on target sim... Pierre ============================================================ // tryusermode.c #include <stdio.h> extern void toUsr(); int dummy() { return 0x1234; } int main() { int i, j; toUsr(); // go to user mode j = dummy(); // dummy() never entered if Redboot active for (i = 0; i < 10; i++) printf("%d\n", i); } ============================================================ // tousr.S .global toUsr toUsr: mov r0, sp stmfd sp!, {r0, lr} // make sp_usr = sp_svc ldmfd sp, {sp, lr}^ // and lr_usr = lr_svc mov r0, #0x10 msr cpsr, r0 // go to usr mode mov pc, lr ============================================================ -- ________________________________________________________________________ Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex ________________________________________________________________________ -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-27 2:04 ` Pierre Habraken @ 2003-03-31 13:11 ` Pierre Habraken 2003-03-31 16:18 ` Jonathan Larmour 0 siblings, 1 reply; 10+ messages in thread From: Pierre Habraken @ 2003-03-31 13:11 UTC (permalink / raw) To: ecos-discuss; +Cc: Jonathan Larmour I just compiled and ran the test program (sources below) on the E7T board, using this time Angel and RDI instead of Redboot: the Arm BL instructions (and thus the call to printf) executes perfectly when the processor is in user mode. As BL fails to execute when the program is run against Redboot, I understand that something in the latter goes wrong as regards user mode execution. Can someone tell me where I could look in Redboot code in order to understand the problem ??? Pierre Pierre Habraken wrote: > > Jonathan Larmour wrote: > > [...] > > > Actually, it seems that it is the 'branch to subroutine' (Arm BL) > > > instruction which hangs when executed in user mode: I wrote a > > > small C program the main function of which merely switches to > > > usr mode and then call a dummy subprogram, and could observe the > > > same behavior, ie the BL instruction hangs. > > > I fear that the problem is related neither to printf nor to newlib > > > or redboot but to the Arm (Samsung implementation) processor... > > > > Theoretically it could be RedBoot since it's up to RedBoot to set > > the next breakpoint to implement the single stepping, although that > > functionality itself is known to work fine elsewhere. It could also > > be some problem with RedBoot's ability to restore state back to user > > mode, although it's not clear why it would work for other > > instructions, but not prior to a BL. What age is this RedBoot? > > There were some significant patches from Mark Salter in this area > > a while back - April 2002. > > I re-built Redboot from CVS sources on last March 3rd. > I attach below the test program I mentioned in my previous message. > > > A hardware problem is always possible, but seems improbable really. > > I agree. BTW, both programs (the one with printf's and the test > program) work fine and behave as expected when compiled/linked without > Redboot support and run on target sim... > > Pierre > > ============================================================ > // tryusermode.c > > #include <stdio.h> > > extern void toUsr(); > > int dummy() { return 0x1234; } > > int main() > { > int i, j; > > toUsr(); // go to user mode > > j = dummy(); // dummy() never entered if Redboot active > > for (i = 0; i < 10; i++) printf("%d\n", i); > } > ============================================================ > // tousr.S > .global toUsr > toUsr: > mov r0, sp > stmfd sp!, {r0, lr} // make sp_usr = sp_svc > ldmfd sp, {sp, lr}^ // and lr_usr = lr_svc > mov r0, #0x10 > msr cpsr, r0 // go to usr mode > mov pc, lr > ============================================================ > -- > ________________________________________________________________________ > Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr > Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 > IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex > ________________________________________________________________________ -- ________________________________________________________________________ Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex ________________________________________________________________________ -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-31 13:11 ` Pierre Habraken @ 2003-03-31 16:18 ` Jonathan Larmour 2003-04-02 12:40 ` Pierre Habraken 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Larmour @ 2003-03-31 16:18 UTC (permalink / raw) To: Pierre Habraken; +Cc: ecos-discuss Pierre Habraken wrote: > I just compiled and ran the test program (sources below) on the E7T > board, using this time Angel and RDI instead of Redboot: the Arm BL > instructions (and thus the call to printf) executes perfectly when the > processor is in user mode. As BL fails to execute when the program is > run against Redboot, I understand that something in the latter goes > wrong as regards user mode execution. > Can someone tell me where I could look in Redboot code in order to > understand the problem ??? Use "set debug remote 1" in GDB and try and find out if anything is not right in the traffic there. After that you should look in hal/common's generic-stub.c which is where the GDB packets get read and mostly acted on. Finally, there's arm/arch's arm_stub.c which contains code to determine the next PC on a single step. That's definitely worth a look given your problem, although the odd thing is how this works for others, but maybe something changed a while back and no-one's noticed yet! I don't have an arm target here to test I'm afraid. Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts --[ "You can complain because roses have thorns, or you ]-- --[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ECOS] printf does not work in user mode on Arm E7T 2003-03-31 16:18 ` Jonathan Larmour @ 2003-04-02 12:40 ` Pierre Habraken 0 siblings, 0 replies; 10+ messages in thread From: Pierre Habraken @ 2003-04-02 12:40 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss Jonathan Larmour wrote: > [...] > Use "set debug remote 1" in GDB and try and find out if anything is > not right in the traffic there. I attach below a trace of a gdb session. At some place, gdb says: "Packet Z0 (software-breakpoint) is NOT supported". Is this Ok ? I am not sure of that because the Arm processor does have a breakpoint instruction (BKPT)... The log confirms that the 'step' command which should enter the function dummy() gets no reply from the target. > Finally, there's arm/arch's arm_stub.c which contains code to > determine the next PC on a single step. That's definitely worth > a look given your problem, although the odd thing is how this works > for others, but maybe something changed a while back and no-one's > noticed yet! I don't have an arm target here to test I'm afraid. I had a (very) quick look yesterday to arm_stub.c and saw nothing weird concerning either computing of next PC for the BL instruction or special processing related to the processor mode (user or supervisor). BTW, no constant value is defined in hal_arch.h for the user mode... Pierre =============================================================== $ arm-elf-gdb GNU gdb 5.3 ... This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf". (gdb) set remotebaud 38400 (gdb) file test-printf Reading symbols from test-printf...done. (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 0x01822ccc in ?? () (gdb) load Loading section .text, size 0x8d80 lma 0x10000 Loading section .init, size 0x1c lma 0x18d80 Loading section .fini, size 0x18 lma 0x18d9c Loading section .rodata, size 0x318 lma 0x18db4 Loading section .data, size 0x7ec lma 0x191cc Loading section .eh_frame, size 0x4 lma 0x199b8 Loading section .ctors, size 0x8 lma 0x199bc Loading section .dtors, size 0x8 lma 0x199c4 Loading section .jcr, size 0x4 lma 0x199cc Start address 0x10100, load size 39120 Transfer rate: 26080 bits/sec, 291 bytes/write. (gdb) list test-printf.c:12 7 int main() 8 { 9 int i; 10 11 i = dummy(); // can step in dummy() 12 printf("%d\n", i); // printf OK 13 14 toUsr(); // switch to user mode 15 16 i = dummy() + 1; // can NOT step in dummy() (gdb) break 16 Breakpoint 1 at 0x1060c: file test-printf.c, line 16. (gdb) set debug remote 1 (gdb) cont Continuing. Sending packet: $Z0,1060c,4#40...Ack Packet received: Packet Z0 (software-breakpoint) is NOT supported Sending packet: $m1060c,4#f7...Ack Packet received: ecffffeb Sending packet: $X1060c,4:þÃÿç#de...Ack Packet received: OK Sending packet: $Hc0#db...Ack Packet received: OK Sending packet: $c#63...Ack Packet received: O343636300A 4660 Packet received: T050f:0c060100;0d:ccff0700; Sending packet: $g#67...Ack Packet received: 1000000001000000009a01008908000002000000500000000000000000000000e0970000fdffffff50000000dcff0700a8030100ccff07000c0601000c0601000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000 Sending packet: $m105e0,4#f8...Ack Packet received: 0dc0a0e1 Sending packet: $m105e4,4#fc...Ack Packet received: 00d82de9 Sending packet: $m105e8,4#00...Ack Packet received: 04b04ce2 Sending packet: $m105ec,4#2b...Ack Packet received: 04d04de2 Sending packet: $m105f0,4#f9...Ack Packet received: f3ffffeb Sending packet: $m105f4,4#fd...Ack Packet received: 0030a0e1 Sending packet: $m105f8,4#01...Ack Packet received: 10300be5 Sending packet: $m105fc,4#2c...Ack Packet received: 2c009fe5 Sending packet: $m10600,4#c4...Ack Packet received: 10101be5 Sending packet: $m10604,4#c8...Ack Packet received: 670000eb Sending packet: $m10608,4#cc...Ack Packet received: e7ffffeb Sending packet: $m1060c,4#f7...Ack Packet received: fedeffe7 Sending packet: $m10610,4#c5...Ack Packet received: 0030a0e1 Sending packet: $m10614,4#c9...Ack Packet received: 013083e2 Sending packet: $m10618,4#cd...Ack Packet received: 10300be5 Sending packet: $m1061c,4#f8...Ack Packet received: 0c009fe5 Sending packet: $X1060c,4:ìÿÿë#f1...Ack Packet received: OK Breakpoint 1, main () at test-printf.c:16 16 i = dummy() + 1; // can NOT step in dummy() (gdb) step Sending packet: $Hc0#db...Ack Packet received: OK Sending packet: $s#73...Ack remote_interrupt called remote_stop called Interrupted while waiting for the program. Give up (and stop debugging it)? (y or n) y (gdb) =============================================================== -- ________________________________________________________________________ Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex ________________________________________________________________________ -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-04-02 12:40 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-26 8:12 [ECOS] printf does not work in user mode on Arm E7T Pierre Habraken 2003-03-26 8:26 ` Andrew Lunn 2003-03-26 11:59 ` Thomas BINDER 2003-03-26 16:49 ` Jonathan Larmour 2003-03-26 12:56 ` Pierre Habraken 2003-03-26 16:54 ` Jonathan Larmour 2003-03-27 2:04 ` Pierre Habraken 2003-03-31 13:11 ` Pierre Habraken 2003-03-31 16:18 ` Jonathan Larmour 2003-04-02 12:40 ` Pierre Habraken
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).