* 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-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
* 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-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-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-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-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-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
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).