Running the hello.c example

Running the hello.c example

[Cristiano Ligieri Pereira]

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

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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
> 
> 

Re: Running the hello.c example

[Ben Elliston]

>>>>> "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

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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
> 

Re: Running the hello.c example

[Ben Elliston]

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

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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
> 

Re: Running the hello.c example

[J. Johnston]

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
> >

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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.

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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.

Re: Running the hello.c example

[J. Johnston]

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
> >

Re: Running the hello.c example

[Cristiano Ligieri Pereira]

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
> 

Re: Running the hello.c example

[Ben Elliston]

>>>>> "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