* Running the hello.c example @ 2001-10-16 15:18 Cristiano Ligieri Pereira 2001-10-17 11:07 ` Cristiano Ligieri Pereira 2001-10-31 15:31 ` Ben Elliston 0 siblings, 2 replies; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-10-16 15:18 UTC (permalink / raw) To: sid Hi all, First of all I've got really impressed when I saw this tools avaiable on RedHat website. Such thing to explore different design choices for embedded systems is very much valuable for both industry and academic (where I am in) environments. Second of all, I've downloaded the source code using cvs and compiled it successfully. As a starting point I'm trying to execute the simple hello.c example described in the FAQ webpage and I'm facing some problems as follows. If I try to execute exacly as described in the website I get the following errors: % arm-elf-gcc -EL hello.c -o hello.x arm-elf-gcc: unrecognized option `-EL' /tools/H-i686-pc-linux-gnu/arm-elf/bin/ld: cannot open crt0.o: No such file or directory collect2: ld returned 1 exit status If I remove the 'L' option and add -I/usr/include and execute the command as follows: % arm-elf-gcc -I/usr/include -E hello.c -o hello.x it works fine and generate the hello.x file, which is post-preprocessing version of the file hello.c (which I thought it was weird since as far as I understood I need the executatble version, isn't it?). Anyways, It turns out to does not work. When trying arm-elf-sid I get the following: % arm-elf-sid hello.x loader: error loading hello.x What am I missing? My main goal is to be able to execute RedHat eCos. Any pointers in this direction? Thanks a lot, Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-10-16 15:18 Running the hello.c example Cristiano Ligieri Pereira @ 2001-10-17 11:07 ` Cristiano Ligieri Pereira 2001-11-10 7:38 ` Ben Elliston 2001-10-31 15:31 ` Ben Elliston 1 sibling, 1 reply; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-10-17 11:07 UTC (permalink / raw) To: sid Hi again, Ok. I kind of worked out my problem but I'm still not successfully. I compiled newlib version 1.8.0 and installed it so that now I have crt0.o (for arm-elf target) on my /tools/arm-elf/lib directory. Now I can compile my application and generate an executable with the following command line: arm-elf-gcc -L/tools/arm-elf/lib -I/tools/arm-elf/include hello.c -o hello.x Actually this was still complaining about the crt0.o file not found. I worked it around copying the file from /tools/arm-elf/lib to my current directory. When I start arm-elf-sid, though, I get the following error: % arm-elf-sid hello.x Fault (software, 0x69) pc=0x8764 If I try to run it through gdb I get nothing on my console: % arm-elf-sid --gdb=2000 -EL & [1] 3554 % arm-elf-gdb hello.x GNU gdb 5.0.92 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"... (gdb) target remote localhost:2000 Remote debugging using localhost:2000 (gdb) load (gdb) cont Continuing. (gdb) Shouldn't I see "Hello world!" printed on my console? Cristiano. PS: I'm doing all this on my RedHat Linux 7.1. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira On Sun, 18 Nov 2001, Cristiano Ligieri Pereira wrote: > > Hi all, > > First of all I've got really impressed when I saw this tools avaiable on > RedHat website. Such thing to explore different design choices for > embedded systems is very much valuable for both industry and academic > (where I am in) environments. > > Second of all, I've downloaded the source code using cvs and compiled it > successfully. As a starting point I'm trying to execute the simple hello.c > example described in the FAQ webpage and I'm facing some problems as > follows. > > If I try to execute exacly as described in the website I get the following > errors: > > % arm-elf-gcc -EL hello.c -o hello.x > > arm-elf-gcc: unrecognized option `-EL' > /tools/H-i686-pc-linux-gnu/arm-elf/bin/ld: cannot open crt0.o: No such > file or directory > collect2: ld returned 1 exit status > > If I remove the 'L' option and add -I/usr/include and execute the command > as follows: > > % arm-elf-gcc -I/usr/include -E hello.c -o hello.x > > it works fine and generate the hello.x file, which is post-preprocessing > version of the file hello.c (which I thought it was weird since as far as > I understood I need the executatble version, isn't it?). > > Anyways, It turns out to does not work. When trying arm-elf-sid I get the > following: > > % arm-elf-sid hello.x > loader: error loading hello.x > > What am I missing? > > My main goal is to be able to execute RedHat eCos. Any pointers in this > direction? > > Thanks a lot, > Cristiano. > > ------------------------------------------------------------ > Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-10-17 11:07 ` Cristiano Ligieri Pereira @ 2001-11-10 7:38 ` Ben Elliston 2001-11-10 11:10 ` Cristiano Ligieri Pereira 0 siblings, 1 reply; 14+ messages in thread From: Ben Elliston @ 2001-11-10 7:38 UTC (permalink / raw) To: Cristiano Ligieri Pereira; +Cc: sid >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: Cristiano> When I start arm-elf-sid, though, I get the following error: Cristiano> % arm-elf-sid hello.x Cristiano> Fault (software, 0x69) pc=0x8764 You might want to use arm-elf-sid --trace-semantics hello.x. Armed (no pun intended) with a disassembly of your program, you should be able to see what's going on. Ben ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-10 7:38 ` Ben Elliston @ 2001-11-10 11:10 ` Cristiano Ligieri Pereira 2001-11-10 16:07 ` Ben Elliston 0 siblings, 1 reply; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-11-10 11:10 UTC (permalink / raw) To: Ben Elliston; +Cc: sid Hi Ben, That's the trace I got: 0xd2a8: BL 0x876c: MOV_REG_IMM_SHIFT 0x8770: STMDB_WB 0x8774: SUB_IMM 0x8778: MOV_REG_IMM_SHIFT 0x877c: BL 0x8758: MOV_REG_IMM_SHIFT 0x875c: STMDB_WB 0x8760: SUB_IMM 0x8764: SWI Fault (software, 0x69) pc=0x8764 and this is the piece of the original code where the error is happening: 00008758 <_swiwrite>: 8758: e1a0c00d mov ip, sp 875c: e92dd800 stmdb sp!, {fp, ip, lr, pc} 8760: e24cb004 sub fp, ip, #4 ; 0x4 8764: ef000069 swi 0x00000069 8768: e91ba800 ldmdb fp, {fp, sp, pc} SWI is software interrupt, right? Looks like I'm trying to execution function 0x69 that doesn't exist? is this right? Why would this happen? This is such a simple example. And one more question..., which configuration is being used (besides ARM processor) once I haven't specified any configuration file, let alone created some configuration. thanks, Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira On Mon, 19 Nov 2001, Ben Elliston wrote: > >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: > > Cristiano> When I start arm-elf-sid, though, I get the following error: > > Cristiano> % arm-elf-sid hello.x > Cristiano> Fault (software, 0x69) pc=0x8764 > > You might want to use arm-elf-sid --trace-semantics hello.x. Armed > (no pun intended) with a disassembly of your program, you should be > able to see what's going on. > > Ben > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-10 11:10 ` Cristiano Ligieri Pereira @ 2001-11-10 16:07 ` Ben Elliston 2001-11-12 19:29 ` Cristiano Ligieri Pereira 2001-11-12 20:03 ` Cristiano Ligieri Pereira 0 siblings, 2 replies; 14+ messages in thread From: Ben Elliston @ 2001-11-10 16:07 UTC (permalink / raw) To: Cristiano Ligieri Pereira; +Cc: sid Hi. >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: Cristiano> 0x8764: SWI Fault (software, 0x69) pc=0x8764 Cristiano> and this is the piece of the original code where the error is happening: Cristiano> 00008758 <_swiwrite>: Cristiano> 8758: e1a0c00d mov ip, sp Cristiano> 875c: e92dd800 stmdb sp!, {fp, ip, lr, pc} Cristiano> 8760: e24cb004 sub fp, ip, #4 ; 0x4 Cristiano> 8764: ef000069 swi 0x00000069 Cristiano> 8768: e91ba800 ldmdb fp, {fp, sp, pc} Cristiano> SWI is software interrupt, right? Looks like I'm trying to execution Cristiano> function 0x69 that doesn't exist? is this right? I think you're on the right track. Cristiano> Why would this happen? This is such a simple example. And one more Cristiano> question..., which configuration is being used (besides ARM processor) Cristiano> once I haven't specified any configuration file, let alone created some Cristiano> configuration. The default ARM system configuration in sid uses the ARM Angel monitor and its associated syscall conventions. My guess is that your build of newlib is targetting some other ARM target where swi 69 is the means by which characters are written. Ben ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-10 16:07 ` Ben Elliston @ 2001-11-12 19:29 ` Cristiano Ligieri Pereira 2001-11-18 17:22 ` Cristiano Ligieri Pereira 2001-11-12 20:03 ` Cristiano Ligieri Pereira 1 sibling, 1 reply; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-11-12 19:29 UTC (permalink / raw) To: Ben Elliston; +Cc: sid > The default ARM system configuration in sid uses the ARM Angel monitor > and its associated syscall conventions. My guess is that your build > of newlib is targetting some other ARM target where swi 69 is the > means by which characters are written. > > Ben So should I change this default configuration or should I somehow recompile newlib so that Angel monitor syscall conventions are applied (I'm guessing that this is possible)? Thanks, Cristiano. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-12 19:29 ` Cristiano Ligieri Pereira @ 2001-11-18 17:22 ` Cristiano Ligieri Pereira 0 siblings, 0 replies; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-11-18 17:22 UTC (permalink / raw) To: Ben Elliston; +Cc: sid > The default ARM system configuration in sid uses the ARM Angel monitor > and its associated syscall conventions. My guess is that your build > of newlib is targetting some other ARM target where swi 69 is the > means by which characters are written. > > Ben So should I change this default configuration or should I somehow recompile newlib so that Angel monitor syscall conventions are applied (I'm guessing that this is possible)? Thanks, Cristiano. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-10 16:07 ` Ben Elliston 2001-11-12 19:29 ` Cristiano Ligieri Pereira @ 2001-11-12 20:03 ` Cristiano Ligieri Pereira 2001-11-13 11:30 ` J. Johnston 2001-11-18 19:11 ` Cristiano Ligieri Pereira 1 sibling, 2 replies; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-11-12 20:03 UTC (permalink / raw) To: Ben Elliston; +Cc: sid These are the number in the file newlib/arm-elf/newlib/libc/sys/arm/swi.h: /**************************************************************************\ * SWI numbers * \**************************************************************************/ #define SWI_WriteC 0x0 #define SWI_Write0 0x2 #define SWI_ReadC 0x4 #define SWI_CLI 0x5 #define SWI_GetEnv 0x10 #define SWI_Exit 0x11 #define SWI_EnterOS 0x16 #define SWI_GetErrno 0x60 #define SWI_Clock 0x61 #define SWI_Time 0x63 #define SWI_Remove 0x64 #define SWI_Rename 0x65 #define SWI_Open 0x66 #define SWI_Close 0x68 #define SWI_Write 0x69 #define SWI_Read 0x6a #define SWI_Seek 0x6b #define SWI_Flen 0x6c #define SWI_IsTTY 0x6e #define SWI_TmpNam 0x6f #define SWI_InstallHandler 0x70 and these are the numbers on the file sid/src/sid/component/gloss/angel.h: enum syscalls /* See also: newlib/libc/sys/arm/swi.h AngelSWI_Reason_* */ { syscall_open = 0x1, syscall_close = 0x2, syscall_writec = 0x3, syscall_write0 = 0x4, syscall_write = 0x5, syscall_read = 0x6, syscall_readc = 0x7, syscall_iserror, syscall_istty = 0x9, syscall_seek = 0xA, syscall_flen = 0xC, syscall_tmpnam = 0xD, syscall_remove = 0xE, syscall_rename = 0xF, syscall_clock = 0x10, syscall_time = 0x11, syscall_system = 0x12, syscall_errno = 0x13, syscall_get_cmdline = 0x15, syscall_heapinfo = 0x16, syscall_report_exception = 0x18 }; If I understood well these number should match, but this is not happening... Am I compiling the wrong verstion of newlib? Thanks, Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira On Mon, 19 Nov 2001, Ben Elliston wrote: > Hi. > > >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: > > Cristiano> 0x8764: SWI Fault (software, 0x69) pc=0x8764 > > Cristiano> and this is the piece of the original code where the error is happening: > > Cristiano> 00008758 <_swiwrite>: > Cristiano> 8758: e1a0c00d mov ip, sp > Cristiano> 875c: e92dd800 stmdb sp!, {fp, ip, lr, pc} > Cristiano> 8760: e24cb004 sub fp, ip, #4 ; 0x4 > Cristiano> 8764: ef000069 swi 0x00000069 > Cristiano> 8768: e91ba800 ldmdb fp, {fp, sp, pc} > > Cristiano> SWI is software interrupt, right? Looks like I'm trying to execution > Cristiano> function 0x69 that doesn't exist? is this right? > > I think you're on the right track. > > Cristiano> Why would this happen? This is such a simple example. And one more > Cristiano> question..., which configuration is being used (besides ARM processor) > Cristiano> once I haven't specified any configuration file, let alone created some > Cristiano> configuration. > > The default ARM system configuration in sid uses the ARM Angel monitor > and its associated syscall conventions. My guess is that your build > of newlib is targetting some other ARM target where swi 69 is the > means by which characters are written. > > Ben > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-12 20:03 ` Cristiano Ligieri Pereira @ 2001-11-13 11:30 ` J. Johnston 2001-11-13 13:12 ` Cristiano Ligieri Pereira 2001-11-19 10:58 ` J. Johnston 2001-11-18 19:11 ` Cristiano Ligieri Pereira 1 sibling, 2 replies; 14+ messages in thread From: J. Johnston @ 2001-11-13 11:30 UTC (permalink / raw) To: Cristiano Ligieri Pereira; +Cc: Ben Elliston, sid Cristiano Ligieri Pereira wrote: > > These are the number in the file newlib/arm-elf/newlib/libc/sys/arm/swi.h: > > /**************************************************************************\ > * SWI numbers * > \**************************************************************************/ > > #define SWI_WriteC 0x0 > #define SWI_Write0 0x2 > #define SWI_ReadC 0x4 > #define SWI_CLI 0x5 > #define SWI_GetEnv 0x10 > #define SWI_Exit 0x11 > #define SWI_EnterOS 0x16 > > #define SWI_GetErrno 0x60 > #define SWI_Clock 0x61 > #define SWI_Time 0x63 > #define SWI_Remove 0x64 > #define SWI_Rename 0x65 > #define SWI_Open 0x66 > > #define SWI_Close 0x68 > #define SWI_Write 0x69 > #define SWI_Read 0x6a > #define SWI_Seek 0x6b > #define SWI_Flen 0x6c > > #define SWI_IsTTY 0x6e > #define SWI_TmpNam 0x6f > #define SWI_InstallHandler 0x70 > Christiano, You likely have built newlib incorrectly. See newlib/configure.host. The default is to define ARM_RDI_MONITOR which activates the Angel code. # newlib_cflags="${newlib_cflags} -DARM_RDP_MONITOR" newlib_cflags="${newlib_cflags} -DARM_RDI_MONITOR" ;; This means that instead of the SWI codes you are quoting above, you will get the AngelSWI_Reason_xxx codes which follow. The value for write is 0x5 which matches what sid is expecting. You should verify that you have not changed these lines and if so, you should clean your newlib build and reconfigure/build again. -- Jeff J. > and these are the numbers on the file sid/src/sid/component/gloss/angel.h: > > enum syscalls /* See also: newlib/libc/sys/arm/swi.h AngelSWI_Reason_* > */ > { > syscall_open = 0x1, > syscall_close = 0x2, > syscall_writec = 0x3, > syscall_write0 = 0x4, > syscall_write = 0x5, > syscall_read = 0x6, > syscall_readc = 0x7, > syscall_iserror, > syscall_istty = 0x9, > syscall_seek = 0xA, > syscall_flen = 0xC, > syscall_tmpnam = 0xD, > syscall_remove = 0xE, > syscall_rename = 0xF, > syscall_clock = 0x10, > syscall_time = 0x11, > syscall_system = 0x12, > syscall_errno = 0x13, > syscall_get_cmdline = 0x15, > syscall_heapinfo = 0x16, > syscall_report_exception = 0x18 > }; > > > If I understood well these number should match, but this is not > happening... Am I compiling the wrong verstion of newlib? > > Thanks, > Cristiano. > > ------------------------------------------------------------ > Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira > > On Mon, 19 Nov 2001, Ben Elliston wrote: > > > Hi. > > > > >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: > > > > Cristiano> 0x8764: SWI Fault (software, 0x69) pc=0x8764 > > > > Cristiano> and this is the piece of the original code where the error is happening: > > > > Cristiano> 00008758 <_swiwrite>: > > Cristiano> 8758: e1a0c00d mov ip, sp > > Cristiano> 875c: e92dd800 stmdb sp!, {fp, ip, lr, pc} > > Cristiano> 8760: e24cb004 sub fp, ip, #4 ; 0x4 > > Cristiano> 8764: ef000069 swi 0x00000069 > > Cristiano> 8768: e91ba800 ldmdb fp, {fp, sp, pc} > > > > Cristiano> SWI is software interrupt, right? Looks like I'm trying to execution > > Cristiano> function 0x69 that doesn't exist? is this right? > > > > I think you're on the right track. > > > > Cristiano> Why would this happen? This is such a simple example. And one more > > Cristiano> question..., which configuration is being used (besides ARM processor) > > Cristiano> once I haven't specified any configuration file, let alone created some > > Cristiano> configuration. > > > > The default ARM system configuration in sid uses the ARM Angel monitor > > and its associated syscall conventions. My guess is that your build > > of newlib is targetting some other ARM target where swi 69 is the > > means by which characters are written. > > > > Ben > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-13 11:30 ` J. Johnston @ 2001-11-13 13:12 ` Cristiano Ligieri Pereira 2001-11-19 13:17 ` Cristiano Ligieri Pereira 2001-11-19 10:58 ` J. Johnston 1 sibling, 1 reply; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-11-13 13:12 UTC (permalink / raw) To: J. Johnston; +Cc: Ben Elliston, sid Hi folks, I hadn't modified the file but I was using newlib-1.8.0, which not even has the options you were talking about. I recompiled newlib, but now with version 1.9.0 and it worked pretty well. Now I can go forward and try out more complex stuff. Thanks for you help, Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira > Christiano, > > You likely have built newlib incorrectly. See newlib/configure.host. The > default > is to define ARM_RDI_MONITOR which activates the Angel code. > > # newlib_cflags="${newlib_cflags} -DARM_RDP_MONITOR" > newlib_cflags="${newlib_cflags} -DARM_RDI_MONITOR" > ;; > > This means that instead of the SWI codes you are quoting above, you will get the > AngelSWI_Reason_xxx codes which follow. The value for write is 0x5 which > matches > what sid is expecting. > > You should verify that you have not changed these lines and if so, you should > clean your newlib build and reconfigure/build again. > > -- Jeff J. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-13 13:12 ` Cristiano Ligieri Pereira @ 2001-11-19 13:17 ` Cristiano Ligieri Pereira 0 siblings, 0 replies; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-11-19 13:17 UTC (permalink / raw) To: J. Johnston; +Cc: Ben Elliston, sid Hi folks, I hadn't modified the file but I was using newlib-1.8.0, which not even has the options you were talking about. I recompiled newlib, but now with version 1.9.0 and it worked pretty well. Now I can go forward and try out more complex stuff. Thanks for you help, Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira > Christiano, > > You likely have built newlib incorrectly. See newlib/configure.host. The > default > is to define ARM_RDI_MONITOR which activates the Angel code. > > # newlib_cflags="${newlib_cflags} -DARM_RDP_MONITOR" > newlib_cflags="${newlib_cflags} -DARM_RDI_MONITOR" > ;; > > This means that instead of the SWI codes you are quoting above, you will get the > AngelSWI_Reason_xxx codes which follow. The value for write is 0x5 which > matches > what sid is expecting. > > You should verify that you have not changed these lines and if so, you should > clean your newlib build and reconfigure/build again. > > -- Jeff J. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-13 11:30 ` J. Johnston 2001-11-13 13:12 ` Cristiano Ligieri Pereira @ 2001-11-19 10:58 ` J. Johnston 1 sibling, 0 replies; 14+ messages in thread From: J. Johnston @ 2001-11-19 10:58 UTC (permalink / raw) To: Cristiano Ligieri Pereira; +Cc: Ben Elliston, sid Cristiano Ligieri Pereira wrote: > > These are the number in the file newlib/arm-elf/newlib/libc/sys/arm/swi.h: > > /**************************************************************************\ > * SWI numbers * > \**************************************************************************/ > > #define SWI_WriteC 0x0 > #define SWI_Write0 0x2 > #define SWI_ReadC 0x4 > #define SWI_CLI 0x5 > #define SWI_GetEnv 0x10 > #define SWI_Exit 0x11 > #define SWI_EnterOS 0x16 > > #define SWI_GetErrno 0x60 > #define SWI_Clock 0x61 > #define SWI_Time 0x63 > #define SWI_Remove 0x64 > #define SWI_Rename 0x65 > #define SWI_Open 0x66 > > #define SWI_Close 0x68 > #define SWI_Write 0x69 > #define SWI_Read 0x6a > #define SWI_Seek 0x6b > #define SWI_Flen 0x6c > > #define SWI_IsTTY 0x6e > #define SWI_TmpNam 0x6f > #define SWI_InstallHandler 0x70 > Christiano, You likely have built newlib incorrectly. See newlib/configure.host. The default is to define ARM_RDI_MONITOR which activates the Angel code. # newlib_cflags="${newlib_cflags} -DARM_RDP_MONITOR" newlib_cflags="${newlib_cflags} -DARM_RDI_MONITOR" ;; This means that instead of the SWI codes you are quoting above, you will get the AngelSWI_Reason_xxx codes which follow. The value for write is 0x5 which matches what sid is expecting. You should verify that you have not changed these lines and if so, you should clean your newlib build and reconfigure/build again. -- Jeff J. > and these are the numbers on the file sid/src/sid/component/gloss/angel.h: > > enum syscalls /* See also: newlib/libc/sys/arm/swi.h AngelSWI_Reason_* > */ > { > syscall_open = 0x1, > syscall_close = 0x2, > syscall_writec = 0x3, > syscall_write0 = 0x4, > syscall_write = 0x5, > syscall_read = 0x6, > syscall_readc = 0x7, > syscall_iserror, > syscall_istty = 0x9, > syscall_seek = 0xA, > syscall_flen = 0xC, > syscall_tmpnam = 0xD, > syscall_remove = 0xE, > syscall_rename = 0xF, > syscall_clock = 0x10, > syscall_time = 0x11, > syscall_system = 0x12, > syscall_errno = 0x13, > syscall_get_cmdline = 0x15, > syscall_heapinfo = 0x16, > syscall_report_exception = 0x18 > }; > > > If I understood well these number should match, but this is not > happening... Am I compiling the wrong verstion of newlib? > > Thanks, > Cristiano. > > ------------------------------------------------------------ > Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira > > On Mon, 19 Nov 2001, Ben Elliston wrote: > > > Hi. > > > > >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: > > > > Cristiano> 0x8764: SWI Fault (software, 0x69) pc=0x8764 > > > > Cristiano> and this is the piece of the original code where the error is happening: > > > > Cristiano> 00008758 <_swiwrite>: > > Cristiano> 8758: e1a0c00d mov ip, sp > > Cristiano> 875c: e92dd800 stmdb sp!, {fp, ip, lr, pc} > > Cristiano> 8760: e24cb004 sub fp, ip, #4 ; 0x4 > > Cristiano> 8764: ef000069 swi 0x00000069 > > Cristiano> 8768: e91ba800 ldmdb fp, {fp, sp, pc} > > > > Cristiano> SWI is software interrupt, right? Looks like I'm trying to execution > > Cristiano> function 0x69 that doesn't exist? is this right? > > > > I think you're on the right track. > > > > Cristiano> Why would this happen? This is such a simple example. And one more > > Cristiano> question..., which configuration is being used (besides ARM processor) > > Cristiano> once I haven't specified any configuration file, let alone created some > > Cristiano> configuration. > > > > The default ARM system configuration in sid uses the ARM Angel monitor > > and its associated syscall conventions. My guess is that your build > > of newlib is targetting some other ARM target where swi 69 is the > > means by which characters are written. > > > > Ben > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-11-12 20:03 ` Cristiano Ligieri Pereira 2001-11-13 11:30 ` J. Johnston @ 2001-11-18 19:11 ` Cristiano Ligieri Pereira 1 sibling, 0 replies; 14+ messages in thread From: Cristiano Ligieri Pereira @ 2001-11-18 19:11 UTC (permalink / raw) To: Ben Elliston; +Cc: sid These are the number in the file newlib/arm-elf/newlib/libc/sys/arm/swi.h: /**************************************************************************\ * SWI numbers * \**************************************************************************/ #define SWI_WriteC 0x0 #define SWI_Write0 0x2 #define SWI_ReadC 0x4 #define SWI_CLI 0x5 #define SWI_GetEnv 0x10 #define SWI_Exit 0x11 #define SWI_EnterOS 0x16 #define SWI_GetErrno 0x60 #define SWI_Clock 0x61 #define SWI_Time 0x63 #define SWI_Remove 0x64 #define SWI_Rename 0x65 #define SWI_Open 0x66 #define SWI_Close 0x68 #define SWI_Write 0x69 #define SWI_Read 0x6a #define SWI_Seek 0x6b #define SWI_Flen 0x6c #define SWI_IsTTY 0x6e #define SWI_TmpNam 0x6f #define SWI_InstallHandler 0x70 and these are the numbers on the file sid/src/sid/component/gloss/angel.h: enum syscalls /* See also: newlib/libc/sys/arm/swi.h AngelSWI_Reason_* */ { syscall_open = 0x1, syscall_close = 0x2, syscall_writec = 0x3, syscall_write0 = 0x4, syscall_write = 0x5, syscall_read = 0x6, syscall_readc = 0x7, syscall_iserror, syscall_istty = 0x9, syscall_seek = 0xA, syscall_flen = 0xC, syscall_tmpnam = 0xD, syscall_remove = 0xE, syscall_rename = 0xF, syscall_clock = 0x10, syscall_time = 0x11, syscall_system = 0x12, syscall_errno = 0x13, syscall_get_cmdline = 0x15, syscall_heapinfo = 0x16, syscall_report_exception = 0x18 }; If I understood well these number should match, but this is not happening... Am I compiling the wrong verstion of newlib? Thanks, Cristiano. ------------------------------------------------------------ Cristiano Ligieri Pereira - http://www.ics.uci.edu/~cpereira On Mon, 19 Nov 2001, Ben Elliston wrote: > Hi. > > >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: > > Cristiano> 0x8764: SWI Fault (software, 0x69) pc=0x8764 > > Cristiano> and this is the piece of the original code where the error is happening: > > Cristiano> 00008758 <_swiwrite>: > Cristiano> 8758: e1a0c00d mov ip, sp > Cristiano> 875c: e92dd800 stmdb sp!, {fp, ip, lr, pc} > Cristiano> 8760: e24cb004 sub fp, ip, #4 ; 0x4 > Cristiano> 8764: ef000069 swi 0x00000069 > Cristiano> 8768: e91ba800 ldmdb fp, {fp, sp, pc} > > Cristiano> SWI is software interrupt, right? Looks like I'm trying to execution > Cristiano> function 0x69 that doesn't exist? is this right? > > I think you're on the right track. > > Cristiano> Why would this happen? This is such a simple example. And one more > Cristiano> question..., which configuration is being used (besides ARM processor) > Cristiano> once I haven't specified any configuration file, let alone created some > Cristiano> configuration. > > The default ARM system configuration in sid uses the ARM Angel monitor > and its associated syscall conventions. My guess is that your build > of newlib is targetting some other ARM target where swi 69 is the > means by which characters are written. > > Ben > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Running the hello.c example 2001-10-16 15:18 Running the hello.c example Cristiano Ligieri Pereira 2001-10-17 11:07 ` Cristiano Ligieri Pereira @ 2001-10-31 15:31 ` Ben Elliston 1 sibling, 0 replies; 14+ messages in thread From: Ben Elliston @ 2001-10-31 15:31 UTC (permalink / raw) To: Cristiano Ligieri Pereira; +Cc: sid >>>>> "Cristiano" == Cristiano Ligieri Pereira <cpereira@ics.uci.edu> writes: Cristiano> % arm-elf-gcc -EL hello.c -o hello.x Cristiano> arm-elf-gcc: unrecognized option `-EL' Cristiano> /tools/H-i686-pc-linux-gnu/arm-elf/bin/ld: cannot open crt0.o: No such Cristiano> file or directory Cristiano> collect2: ld returned 1 exit status I'm not sure why this is happening; are you sure that -EL is the right command line option to build a little endian ARM binary? I'm not so sure. You should check the documentation. Cristiano> % arm-elf-gcc -I/usr/include -E hello.c -o hello.x Cristiano> it works fine and generate the hello.x file, which is post-preprocessing Cristiano> version of the file hello.c (which I thought it was weird since as far as Cristiano> I understood I need the executatble version, isn't it?). Cristiano> Anyways, It turns out to does not work. When trying arm-elf-sid I get the Cristiano> following: Cristiano> % arm-elf-sid hello.x Cristiano> loader: error loading hello.x This won't work -- you've emitted preprocessed source to hello.x. hello.x needs to be a valid ELF object file (you can test this with file(1) when you think you've got it right). Ben ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2001-11-19 21:17 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-10-16 15:18 Running the hello.c example Cristiano Ligieri Pereira 2001-10-17 11:07 ` Cristiano Ligieri Pereira 2001-11-10 7:38 ` Ben Elliston 2001-11-10 11:10 ` Cristiano Ligieri Pereira 2001-11-10 16:07 ` Ben Elliston 2001-11-12 19:29 ` Cristiano Ligieri Pereira 2001-11-18 17:22 ` Cristiano Ligieri Pereira 2001-11-12 20:03 ` Cristiano Ligieri Pereira 2001-11-13 11:30 ` J. Johnston 2001-11-13 13:12 ` Cristiano Ligieri Pereira 2001-11-19 13:17 ` Cristiano Ligieri Pereira 2001-11-19 10:58 ` J. Johnston 2001-11-18 19:11 ` Cristiano Ligieri Pereira 2001-10-31 15:31 ` Ben Elliston
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).