RE: gcc compile

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

Hi! Do you know, what should I do if I want to use target
simulator in arm-elf-gdb debugger? 
Normally I use have a monitor program,
which handles software traps. 
That´s why the code crashes on the simulator.

Is there s.th. similar to the "sim" option for arm?
jens-christian
Am Fre, 19 Jan 2001 schrieben Sie:
> >-----Original Message-----
> >From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]
> 
> >I am unable to find such a think (which sounds nice) in my version of
> >gcc, which i compiled for i960 about a year ago:
> >,----------------------------- [ gcc -v ] -----------------------------
> >| Reading specs from
> >| /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
> >| gcc version 2.95.2 19991024 (release)
> >`----------------------------------------------------------------------
> >2.92.2 shoudn't be sooo old - right?
> >
> >Is the "sim" option a new feature, a special patch, or something enabled
> >for some special cpus?
> 
>   Yep.  Sorry, but it's for powerpc only.  The GDB debugger comes with a 
> ppc simulator, and the -sim flag compiles code to run with it.  There aren't
> simulators for any other cpus.  This is from the "IBM RS/6000 and PowerPC
> Options" section of the manual:
> 
> ----------snip!--------------
> -msim 
> On embedded PowerPC systems, assume that the startup module is called
> `sim-crt0.o' and the standard C libraries are `libsim.a' and `libc.a'. This
> is default for `powerpc-*-eabisim' configurations. 
> ----------snip!--------------
> 
>        DaveK
> -- 
> The Boulder Pledge: "Under no circumstances will I ever purchase anything 
> offered to me as the result of an unsolicited email message. Nor will I 
> forward chain letters, petitions, mass mailings, or virus warnings to large 
> numbers of others. This is my contribution to the survival of the online
> community."
> 
> 
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> www.mimesweeper.com
> **********************************************************************
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
-------------------------------------------------------

-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Jens-Christian Lache wrote:

> Hi! Do you know, what should I do if I want to use target
> simulator in arm-elf-gdb debugger?
> Normally I use have a monitor program,
> which handles software traps.
> That´s why the code crashes on the simulator.

Hi Jean-Christian.

To use the built-in gdb simulator for your arm-elf target, you have to remove all
your environment, use the default starting files provided by gcc and newlib
(crt0.o, crtbegin.o and crtend.o) and the simulator environment provided by gdb
(the simulator library for your target).
The main steps are :
1. Use the default crt0.o made by newlib (installed under "arm-elf/lib/" of your
installation directory).
2. Use the default crtbegin.o and crtend.o made by gcc (installed under
"lib/gcc-lib/arm-elf/2.95.2/" of your installation directory).
2. Use the default internal linker script of ld.
3. Link your program with libarm-elf-sim.a (delivered by GDB).
4. launch : arm-elf-gdb <your program>.
5. (gdb) target sim
    (gdb) load <your program>
    (gdb) run

To compile and link an hello_world.c for your arm-elf target :
arm-elf-gcc -g -c hello_world.c
arm-elf-gcc -L<your installation directory>/lib -larm-elf-sim -g  hello_world.o -o
hello_world

Remark : You did not have to build your cross tools with specific flags.

Pierre.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

Hi! Do you know, what should I do if I want to use target
simulator in arm-elf-gdb debugger? 
Normally I use have a monitor program,
which handles software traps. 
That´s why the code crashes on the simulator.

Is there s.th. similar to the "sim" option for arm?
jens-christian
Am Fre, 19 Jan 2001 schrieben Sie:
> >-----Original Message-----
> >From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]
> 
> >I am unable to find such a think (which sounds nice) in my version of
> >gcc, which i compiled for i960 about a year ago:
> >,----------------------------- [ gcc -v ] -----------------------------
> >| Reading specs from
> >| /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
> >| gcc version 2.95.2 19991024 (release)
> >`----------------------------------------------------------------------
> >2.92.2 shoudn't be sooo old - right?
> >
> >Is the "sim" option a new feature, a special patch, or something enabled
> >for some special cpus?
> 
>   Yep.  Sorry, but it's for powerpc only.  The GDB debugger comes with a 
> ppc simulator, and the -sim flag compiles code to run with it.  There aren't
> simulators for any other cpus.  This is from the "IBM RS/6000 and PowerPC
> Options" section of the manual:
> 
> ----------snip!--------------
> -msim 
> On embedded PowerPC systems, assume that the startup module is called
> `sim-crt0.o' and the standard C libraries are `libsim.a' and `libc.a'. This
> is default for `powerpc-*-eabisim' configurations. 
> ----------snip!--------------
> 
>        DaveK
> -- 
> The Boulder Pledge: "Under no circumstances will I ever purchase anything 
> offered to me as the result of an unsolicited email message. Nor will I 
> forward chain letters, petitions, mass mailings, or virus warnings to large 
> numbers of others. This is my contribution to the survival of the online
> community."
> 
> 
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> www.mimesweeper.com
> **********************************************************************
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
-------------------------------------------------------

-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Jens-Christian Lache wrote:

> Hi! Do you know, what should I do if I want to use target
> simulator in arm-elf-gdb debugger?
> Normally I use have a monitor program,
> which handles software traps.
> That´s why the code crashes on the simulator.

Hi Jean-Christian.

To use the built-in gdb simulator for your arm-elf target, you have to remove all
your environment, use the default starting files provided by gcc and newlib
(crt0.o, crtbegin.o and crtend.o) and the simulator environment provided by gdb
(the simulator library for your target).
The main steps are :
1. Use the default crt0.o made by newlib (installed under "arm-elf/lib/" of your
installation directory).
2. Use the default crtbegin.o and crtend.o made by gcc (installed under
"lib/gcc-lib/arm-elf/2.95.2/" of your installation directory).
2. Use the default internal linker script of ld.
3. Link your program with libarm-elf-sim.a (delivered by GDB).
4. launch : arm-elf-gdb <your program>.
5. (gdb) target sim
    (gdb) load <your program>
    (gdb) run

To compile and link an hello_world.c for your arm-elf target :
arm-elf-gcc -g -c hello_world.c
arm-elf-gcc -L<your installation directory>/lib -larm-elf-sim -g  hello_world.o -o
hello_world

Remark : You did not have to build your cross tools with specific flags.

Pierre.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Yves Rutschle]

> Even at the beginning of "start" the cpsr is equal to 0x10;
> 
> I have added a mode switch to user mode to crt0.S
> and will install the proposed swi handler.


Aha, good one, I didn't think about that. An ARM core starts
up in SVC (otherwise you can't setup anything). So you need
to switch to usermode indeed.

Probably your hardware initialisation was setting user
mode without your knowing, whereas the simulator only does
what you tell it to do.

Cheers,
Y.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

In message < 200101231017.KAA28604@cam-mail2.cambridge.arm.com >, Richard Earnsha
w writes:
>> You could try `__attribute__ (( interrupt ("SWI")))' with GCC.  This should 
>> suffice for very simple handlers, though you will still need to write in 
>> assembler for anything more sophisticated.
>
>This is new in the CVS version; it wasn't in 2.95.x (at least, if it was, 
>it probably didn't work very well).

Oops, you're right.  It's not in 2.95 at all.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

ok, I forgot to include the linker script. The makefile should be more common
now, please adjust 
TOOLDIR=/home/hiwi/lache/tools
and 
CC=$(TOOLDIR)/bin/arm-elf-gcc
to the appropriate values.

Thank you for looking at the code!

Jens-Christian


 Am Mon, 22 Jan 2001 schrieben Sie:
> > Unfortunately the ARM simulator does not support the several 
> > CPU modes, that
> > the ARM7TDMI has. I made a software trap using "swi", and the 
> > pc was set
> > correctly to 0x8. It did also execute the jump instruction 
> > from this place
> > leading to my own swi handler. But when leaving it, returning to the
> > code containing the swi, the mode was still 0x10, which is 
> > not supervisor
> > mode. 
> 
> 
> How do you return from your SWI handler? Don't forget
> you have to make
> 	movs	pc, lr
> to copy SPSR in CPSR at the same time you return, so
> the mode gets changed.
> 
> CPU modes have been in existence since the very beginning
> of the ARM cores, so I doubt it's not supported!
> 
> Cheers,
> Yves
> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

[-- Attachment #2: adeos.tgz --]
[-- Type: application/x-gzip, Size: 13816 bytes --]

Re: gcc compile

[Gerrit Peter Haase]

Sascha Andres schrieb:
> hi,
> i've build the gcc with the following command line:
> 
> there is no crt0.o for arm-elf in the/tools dir.
> so how to compile the missing file(s) ?

You need to build a cross-newlib too?

-- 
Gerrit

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jonathan Larmour]

Sascha Andres wrote:
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> hi,
> i've build the gcc with the following command line:
> 
> /src/gcc/gcc-2.95.2/configure --target=arm-elf \
>     --prefix=/tools \
>     --exec-prefix=/tools/H-i686-pc-linux-gnu \
>     --with-gnu-as --with-gnu-ld --with-newlib \
>     --nfp \
>    -v 2>&1 | tee configure.out
> make -w all-gcc install-gcc \
>     LANGUAGES="c c++" 2>&1 | tee make.out
> 
> the binutils are build without any errors and this
> runs through too. but when compiling a simple c file
> i get the message
> 
> 'crt0.o not found.'.
> 
> there is no crt0.o for arm-elf in the/tools dir.
> so how to compile the missing file(s) ?

You need to build newlib for your target. Read the crossgcc FAQ (see the
end of this message).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

gcc compile

[Sascha Andres]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,
i've build the gcc with the following command line:

/src/gcc/gcc-2.95.2/configure --target=arm-elf \
    --prefix=/tools \
    --exec-prefix=/tools/H-i686-pc-linux-gnu \
    --with-gnu-as --with-gnu-ld --with-newlib \
    --nfp \
   -v 2>&1 | tee configure.out
make -w all-gcc install-gcc \
    LANGUAGES="c c++" 2>&1 | tee make.out

the binutils are build without any errors and this
runs through too. but when compiling a simple c file
i get the message

'crt0.o not found.'.

there is no crt0.o for arm-elf in the/tools dir.
so how to compile the missing file(s) ?

sascha

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOmcmlGYZ6Od193QxEQIMPgCePNq7BgEFW2m187DO3GPUnPkaksQAoOYw
Kz1bxqZv/56OW487RAvpW1DL
=yi3a
-----END PGP SIGNATURE-----


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

Hello everybody! The ARM Simulator does support different Modes. I just have
had the wrong arm-elf-gdb in my PATH. It was the last stable version:
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.

Even at the beginning of "start" the cpsr is equal to 0x10;

I have added a mode switch to user mode to crt0.S
and will install the proposed swi handler.

Thank´s a lot,

Jens-Christian



 Am Mon, 22 Jan 2001 schrieben Sie:
> In message < 01012211514701.02376@lab04 >, Jens-Christian Lache writes:
> >Unfortunately the ARM simulator does not support the several CPU modes, that
> >the ARM7TDMI has. I made a software trap using "swi", and the pc was set
> >correctly to 0x8. It did also execute the jump instruction from this place
> >leading to my own swi handler. But when leaving it, returning to the
> >code containing the swi, the mode was still 0x10, which is not supervisor
> >mode. 
> 
> Can you give a concrete example of the code that you think is going wrong?  
> The simulator certainly does support different modes - all ARM processors have 
> these, not just ARM7TDMI.
> 
> p.
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

>  To the best of my knowledge there is only a ppc target simulator for gdb.
>I don't know what you are referring to when you say "That=B4s why the code
>crashes on the simulator"; is it that you have an ARM simulator that is
>separate from the GNU software, maybe a commercial product?

This isn't true, in fact.  GDB ships with simulators for several cpus, including 
ARM.  Take a look in the `sim' subdirectory of the source tree for the full 
list.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

Am Mon, 22 Jan 2001 schrieben Sie:
> > Unfortunately the ARM simulator does not support the several 
> > CPU modes, that
> > the ARM7TDMI has. I made a software trap using "swi", and the 
> > pc was set
> > correctly to 0x8. It did also execute the jump instruction 
> > from this place
> > leading to my own swi handler. But when leaving it, returning to the
> > code containing the swi, the mode was still 0x10, which is 
> > not supervisor
> > mode. 
> 
> 
> How do you return from your SWI handler? Don't forget
> you have to make
> 	movs	pc, lr
> to copy SPSR in CPSR at the same time you return, so
> the mode gets changed.
> 
> CPU modes have been in existence since the very beginning
> of the ARM cores, so I doubt it's not supported!
> 
> Cheers,
> Yves
Hello!
This is how the swi_handler looks like. You may have a look at the source code.
Please say make and run it on the gdb sim. In my opinion it wasn´t in SV.
I have tested the code on the eb01. After swi the proc is in SV.


Thank you all for your help!!!

Jens-Christian

0x2018d28 <swi_handler__Fi>:	mov	r12, sp
0x2018d2c <swi_handler__Fi+4>:	stmdb	sp!, {r11, r12, lr, pc}
0x2018d30 <swi_handler__Fi+8>:	sub	r11, r12, #4	; 0x4
0x2018d34 <swi_handler__Fi+12>:	sub	sp, sp, #12	; 0xc
0x2018d38 <swi_handler__Fi+16>:	str	r0, [r11, -#16]
0x2018d3c <swi_handler__Fi+20>:	mov	r3, #68	; 0x44
0x2018d40 <swi_handler__Fi+24>:	str	r3, [r11, -#20]
0x2018d44 <swi_handler__Fi+28>:	ldr	r3, [r11, -#16]
0x2018d48 <swi_handler__Fi+32>:	cmp	r3, #1	; 0x1
0x2018d4c <swi_handler__Fi+36>:	beq	0x2018d54 <swi_handler__Fi+44>
0x2018d50 <swi_handler__Fi+40>:	b	0x2018d8c <swi_handler__Fi+100>
0x2018d54 <swi_handler__Fi+44>:	mrs	r0, cpsr
0x2018d58 <swi_handler__Fi+48>:	orr	r0, r0, #192	; 0xc0
0x2018d5c <swi_handler__Fi+52>:	msr	cpsr_all, r0
0x2018d60 <swi_handler__Fi+56>:	mrs	r3, cpsr
0x2018d64 <swi_handler__Fi+60>:	str	r3, [r11, -#24]
0x2018d68 <swi_handler__Fi+64>:	ldr	r3, [r11, -#20]
0x2018d6c <swi_handler__Fi+68>:	ldr	r2, [r11, -#24]
0x2018d70 <swi_handler__Fi+72>:	str	r2, [r3]
0x2018d74 <swi_handler__Fi+76>:	mvn	r3, #65280	; 0xff00
0x2018d78 <swi_handler__Fi+80>:	sub	r3, r3, #207	; 0xcf
0x2018d7c <swi_handler__Fi+84>:	str	r3, [r11, -#20]
0x2018d80 <swi_handler__Fi+88>:	ldr	r3, [r11, -#20]
0x2018d84 <swi_handler__Fi+92>:	mov	r2, #22	; 0x16
0x2018d88 <swi_handler__Fi+96>:	str	r2, [r3]
0x2018d8c <swi_handler__Fi+100>:	b	0x2018d90 <swi_handler__Fi+104>
0x2018d90 <swi_handler__Fi+104>:	b	0x2018d98 <swi_handler__Fi+112>
0x2018d94 <swi_handler__Fi+108>:	b	0x2018d98 <swi_handler__Fi+112>
0x2018d98 <swi_handler__Fi+112>:	ldmdb	r11, {r11, sp, pc}


> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

[-- Attachment #2: adeos.tgz --]
[-- Type: application/x-gzip, Size: 11878 bytes --]

RE: gcc compile

[Yves Rutschle]

> Unfortunately the ARM simulator does not support the several 
> CPU modes, that
> the ARM7TDMI has. I made a software trap using "swi", and the 
> pc was set
> correctly to 0x8. It did also execute the jump instruction 
> from this place
> leading to my own swi handler. But when leaving it, returning to the
> code containing the swi, the mode was still 0x10, which is 
> not supervisor
> mode. 


How do you return from your SWI handler? Don't forget
you have to make
	movs	pc, lr
to copy SPSR in CPSR at the same time you return, so
the mode gets changed.

CPU modes have been in existence since the very beginning
of the ARM cores, so I doubt it's not supported!

Cheers,
Yves



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

>I can't find any 'sim' directory under gcc.
>Is 'sim' somewhere else in the tree?

It's bundled with GDB, not GCC.  I imagine it's included in the gdb-5.0 
tarball.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Hua Ji]

 

Sascha Andres schrieb:
> hi,
> i've build the gcc with the following command line:
> 
> there is no crt0.o for arm-elf in the/tools dir.
> so how to compile the missing file(s) ?

>You need to build a cross-newlib too?

Hua: I guess this is no special related to newlib, but with that he didn't
explicitely specify an target OS. With arm-elf configurations, system will
not **AUTOMATICALLY* go for the __start symbol and other part, which is used
for initialization before cpu gives control to __main entry. 

My (personal) suggestion is: This is not a error. Leave it, if you are doing
your coding for the raw board without any os support(like linux).

For testing, you can use gcc -msim...., so that you will no problem for
creating an executable and can be run with the powerpc-arm-elf-run, which
should be located in your ./bin directory. 

For real development, sure we need provide a start.S in which the __start
entry will be provided. So that our codes can be deploed onto the RAW board.

Wish I am correct(keep my fingers crossed). However, folks, do point out if
I am wrong. I just wish we can grow together!

Hua

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Richard Earnshaw]

> >I don't think you can create a whole swi handler in C (unless
> >gcc has extensions I don't know about. the arm C doesn't
> >anyway).
> 
> You could try `__attribute__ (( interrupt ("SWI")))' with GCC.  This should 
> suffice for very simple handlers, though you will still need to write in 
> assembler for anything more sophisticated.
> 

This is new in the CVS version; it wasn't in 2.95.x (at least, if it was, 
it probably didn't work very well).

R.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

>I don't think you can create a whole swi handler in C (unless
>gcc has extensions I don't know about. the arm C doesn't
>anyway).

You could try `__attribute__ (( interrupt ("SWI")))' with GCC.  This should 
suffice for very simple handlers, though you will still need to write in 
assembler for anything more sophisticated.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5908 bytes --]

Am Fre, 19 Jan 2001 schrieben Sie:
> Hi Jens,
> 
>   To the best of my knowledge there is only a ppc target simulator for gdb.
> I don't know what you are referring to when you say "That´s why the code
> crashes on the simulator"; is it that you have an ARM simulator that is
> separate from the GNU software, maybe a commercial product?

It is build in the arm-elf-gdb, so it´s free. The simulator may come 
from Berkely university, but I am not sure. I compiled newlib
with 
newlib_cflags="${newlib_cflags} -DARM_RDI_MONITOR"
turned off in configure.host. It still does make a call to angel
while doing 
pStack     = new int[stackSize];
in "libcfunc.c" , abort:

-	0x201c864	<abort>:		mov	r12, sp
-	0x201c868	<abort+4>:		stmdb	sp!, {r11, r12, lr, pc}
-	0x201c86c	<abort+8>:		sub	r11, r12, #4	; 0x4
-	0x201c870	<abort+12>:		mov	r3, #131072	; 0x20000
-	0x201c874	<abort+16>:		add	r3, r3, #34	; 0x22
-	0x201c878	<abort+20>:		mov	r2, #24	; 0x18
-	0x201c87c	<abort+24>:		mov	r0, r2
-	0x201c880	<abort+28>:		mov	r1, r3
-	0x201c884	<abort+32>:		swi	0x00123456
-	0x201c888	<abort+36>:		mov	r2, r0
-	0x201c88c	<abort+40>:		ldmdb	r11, {r11, sp, pc}

(Can anybody have a look at the compiling output? Couldn´t find "rdi" or "angel"
in it anymore)

At the moment, I write my own memory allocator. I want to disable my monitor
program on the target in the final version of the RTOS that I am porting at the
moment. I still hope just to use new int[stackSize]; , leaving the "dirty work"
to newlib.

Jens-Christian

> 
> 
>          DaveK
> -- 
> The Boulder Pledge: "Under no circumstances will I ever purchase anythingo
>  ffered to me as the result of an unsolicited email message. Nor will I 
> forward chain letters, petitions, mass mailings, or virus warnings to largen
>  umbers of others. This is my contribution to the survival of the online
> community." 
> 
> >-----Original Message-----
> >From: Jens-Christian Lache [ mailto:lache@tu-harburg.de ]
> >Sent: 19 January 2001 10:11
> >To: David Korn
> >Subject: RE: gcc compile
> >
> >
> >Hi! Do you know, what should I do if I want to use target
> >simulator in arm-elf-gdb debugger? 
> >Normally I use have a monitor program,
> >which handles software traps. 
> >That´s why the code crashes on the simulator.
> >
> >Is there s.th. similar to the "sim" option for arm?
> >jens-christian
> >Am Fre, 19 Jan 2001 schrieben Sie:
> >> >-----Original Message-----
> >> >From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]
> >> 
> >> >I am unable to find such a think (which sounds nice) in my 
> >version of
> >> >gcc, which i compiled for i960 about a year ago:
> >> >,----------------------------- [ gcc -v ] 
> >-----------------------------
> >> >| Reading specs from
> >> >| 
> >/usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
> >> >| gcc version 2.95.2 19991024 (release)
> >> 
> >>`-------------------------------------------------------------
> >---------
> >> >2.92.2 shoudn't be sooo old - right?
> >> >
> >> >Is the "sim" option a new feature, a special patch, or 
> >something enabled
> >> >for some special cpus?
> >> 
> >>   Yep.  Sorry, but it's for powerpc only.  The GDB debugger 
> >comes with a 
> >> ppc simulator, and the -sim flag compiles code to run with 
> >it.  There aren't
> >> simulators for any other cpus.  This is from the "IBM 
> >RS/6000 and PowerPC
> >> Options" section of the manual:
> >> 
> >> ----------snip!--------------
> >> -msim 
> >> On embedded PowerPC systems, assume that the startup module is called
> >> `sim-crt0.o' and the standard C libraries are `libsim.a' and 
> >`libc.a'. This
> >> is default for `powerpc-*-eabisim' configurations. 
> >> ----------snip!--------------
> >> 
> >>        DaveK
> >> -- 
> >> The Boulder Pledge: "Under no circumstances will I ever 
> >purchase anything 
> >> offered to me as the result of an unsolicited email message. 
> >Nor will I 
> >> forward chain letters, petitions, mass mailings, or virus 
> >warnings to large 
> >> numbers of others. This is my contribution to the survival 
> >of the online
> >> community."
> >> 
> >> 
> >> 
> >**********************************************************************
> >> This email and any files transmitted with it are confidential and
> >> intended solely for the use of the individual or entity to whom they
> >> are addressed. If you have received this email in error please notify
> >> the system manager.
> >> 
> >> This footnote also confirms that this email message has been swept by
> >> MIMEsweeper for the presence of computer viruses.
> >> 
> >> www.mimesweeper.com
> >> 
> >**********************************************************************
> >> 
> >> ------
> >> Want more information?  See the CrossGCC FAQ, 
> > http://www.objsw.com/CrossGCC/
> >> Want to unsubscribe? Send a 
> >note to crossgcc-unsubscribe@sourceware.cygnus.com
> >-- 
> >
> >
> >Jens-Christian Lache
> >Technische Universitaet Hamburg-Harburg
> >www.tu-harburg.de/~sejl1601
> >Mail:
> >lache@tu-harburg.de
> >lache@ngi.de
> >Tel.:
> >+0491759610756
> >
> 
> 
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> www.mimesweeper.com
> **********************************************************************
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Yves Rutschle]

Hallo,

> I have tested the code on the eb01. After swi the proc is in SV.

Therefore it's not because of the simulator :)

> 0x2018d28 <swi_handler__Fi>:	mov	r12, sp
> 0x2018d2c <swi_handler__Fi+4>:	stmdb	sp!, {r11, r12, lr, pc}
> 0x2018d30 <swi_handler__Fi+8>:	sub	r11, r12, #4	; 0x4
> 0x2018d34 <swi_handler__Fi+12>:	sub	sp, sp, #12	; 0xc
[snipped swi routine]
> 0x2018d98 <swi_handler__Fi+112>:	ldmdb	r11, {r11, sp, pc}

This code won't set CPSR back to SPSR; Try to add a hat
at the end of the return instruction:
	ldmdb r11, {r11, sp, pc}^
(the hat activates the copy of SPSR to CPSR same as movs pc,lr)

>Don?t know what I am doing wrong. This does also not work:
>void swi_handler(int reason) {
>  switch(reason) {
>  case REASON_CHANGE_TO_SV :
>    asm volatile ("mrs r0,cpsr": : :"r0");
>    asm volatile ("orr r0, r0, #192": : :"r0");
>    asm volatile ("msr cpsr, r0");
>  default :
>    break;
>  }
>  asm volatile("movs    pc, lr");
>}

Huh. What do you think happens to the stack when you leave
like that? :-) (hint: you pushed 4 registers when entering
the routine...)

I don't think you can create a whole swi handler in C (unless
gcc has extensions I don't know about. the arm C doesn't
anyway).

I'd advise you to use an assembly top-level handler such
as:

	stmdf sp!, {r0-r3, lr}
	ldr	r0, [lr,#-4]
	bic	r0, r0, #0xff000000
	mov	r1, sp			; r1 = SWI number
	mrs	r2, spsr
	stmfd	sp!, {r2}			; keep spsr in case of nested swi's
	bl	C_Handler
	ldmfd	sp!, {r2}
	msr	spsr, r2			; restore spsr
	ldmfd	sp!, {r0-r3, pc}^		; return, restore cpsr from spsr

(this is straight from ADS' developer guide, by the way)

Then your C handler looks like:

void C_Handler( int swi_number, unsigned int * stack )
{
    printf( "got swi %d\n", swi_number );
}

Hope that helps!

Yves.






------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Kai Ruottu]

Helmut Kolb wrote:
> 
> es klopfte Hua Ji in seine tastatur:
> > For testing, you can use gcc -msim...., so that you will no problem for
> > creating an executable and can be run with the powerpc-arm-elf-run, which
> > should be located in your ./bin directory.
>
> ... i have read a few times about the "-msim" switch of gcc.
> 
> I am unable to find such a think (which sounds nice) in my version of
> gcc, which i compiled for i960 about a year ago:
> ,----------------------------- [ gcc -v ] -----------------------------
> | Reading specs from
> | /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
> | gcc version 2.95.2 19991024 (release)
> `----------------------------------------------------------------------
> 2.92.2 shoudn't be sooo old - right?
> 
> Is the "sim" option a new feature, a special patch, or something enabled
> for some special cpus?

 The option is available probably only for PowerPC, I don't remember it used
elsewhere.

 The 'i960-coff' target uses the 'mon960' as the only available target (in newlib)
and the i960-simulator in GDB seems to simulate it. Ok, here is a clip from my
'specs' for 'i960-coff':

------------------------ clip ------------------------------------------
*endfile:


*link:
%{mka:-AKA}%{mkb:-AKB}%{msa:-ASA}%{msb:-ASB} %{mmc:-AMC}%{mca:-ACA}%{mcc:-ACC}%{mcf:-ACF}
%{mja:-AJX}%{mjd:-AJX}%{mjf:-AJX}%{mrp:-AJX} %{mbout:-Fbout}%{mcoff:-Fcoff} %{mlink-relax:-relax} -T mon960.ld%s

*lib:
-lc -lmon960 -lgcc -lc

*libgcc:


*startfile:
crt0%O%s
------------------------ clip ------------------------------------------

 If I compile the C program for the default 'mon960' and use the '-mka'
(I remember the KA being the only supported model in the simulator) :

e:\usr\local\samples>gcc-i960-coff -mka -g -o tst_i960ka.gx tprintf.c

and then try it with the standalone simulator (from GDB), it runs without
any problems (even under Win32...) :

e:\usr\local\samples>run-i960-coff-mw tst_i960ka.gx
%.4x:   `0012'
%04x:   `0012'
%4.4x:  `0012'
%04.4x: `0012'
%4.3x:  ` 012'
%04.3x: ` 012'
%.*x:   `0012'
%0*x:   `0012'
%*.*x:  `0012'
%0*.*x: `0012'
bad format:     "z"
nil pointer (padded):   "       0x0"
decimal negative:       "-2345"
octal negative: "37777773327"
hex negative:   "fffff6d7"
long decimal number:    "-123456"
long octal negative:    "37777773327"
long unsigned decimal number:   "4294843840"
zero-padded LDN:        "-000123456"
< snip >

 Hopefully this was your problem and can help you to solve it...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

Am Mon, 22 Jan 2001 schrieben Sie:
> Hallo,
> 
> > I have tested the code on the eb01. After swi the proc is in SV.

Sorry, I wanted to say: I have tested it  on both the sim and the aeb and it
worked  on the aeb but not on the sim.

> 
> Therefore it's not because of the simulator :)
> 
> > 0x2018d28 <swi_handler__Fi>:	mov	r12, sp
> > 0x2018d2c <swi_handler__Fi+4>:	stmdb	sp!, {r11, r12, lr, pc}
> > 0x2018d30 <swi_handler__Fi+8>:	sub	r11, r12, #4	; 0x4
> > 0x2018d34 <swi_handler__Fi+12>:	sub	sp, sp, #12	; 0xc
> [snipped swi routine]
> > 0x2018d98 <swi_handler__Fi+112>:	ldmdb	r11, {r11, sp, pc}
> 
> This code won't set CPSR back to SPSR; Try to add a hat
> at the end of the return instruction:
> 	ldmdb r11, {r11, sp, pc}^
> (the hat activates the copy of SPSR to CPSR same as movs pc,lr)
> 
> >Don?t know what I am doing wrong. This does also not work:
> >void swi_handler(int reason) {
> >  switch(reason) {
> >  case REASON_CHANGE_TO_SV :
> >    asm volatile ("mrs r0,cpsr": : :"r0");
> >    asm volatile ("orr r0, r0, #192": : :"r0");
> >    asm volatile ("msr cpsr, r0");
> >  default :
> >    break;
> >  }
> >  asm volatile("movs    pc, lr");
> >}
> 
> Huh. What do you think happens to the stack when you leave
> like that? :-) (hint: you pushed 4 registers when entering
> the routine...)
> 
> I don't think you can create a whole swi handler in C (unless
> gcc has extensions I don't know about. the arm C doesn't
> anyway).
> 
> I'd advise you to use an assembly top-level handler such
> as:
> 
> 	stmdf sp!, {r0-r3, lr}
> 	ldr	r0, [lr,#-4]
> 	bic	r0, r0, #0xff000000
> 	mov	r1, sp			; r1 = SWI number
> 	mrs	r2, spsr
> 	stmfd	sp!, {r2}			; keep spsr in case of nested swi's
> 	bl	C_Handler
> 	ldmfd	sp!, {r2}
> 	msr	spsr, r2			; restore spsr
> 	ldmfd	sp!, {r0-r3, pc}^		; return, restore cpsr from spsr
> 
> (this is straight from ADS' developer guide, by the way)
> 
> Then your C handler looks like:
> 
> void C_Handler( int swi_number, unsigned int * stack )
> {
>     printf( "got swi %d\n", swi_number );
> }
> 
> Hope that helps!
 Me too! :-)
I will try it!

Jens-Christian

> 
> Yves.
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Richard Earnshaw]

lache@tu-harburg.de said:
> Unfortunately the ARM simulator does not support the several CPU
> modes, that the ARM7TDMI has. I made a software trap using "swi", and
> the pc was set correctly to 0x8. It did also execute the jump
> instruction from this place leading to my own swi handler. But when
> leaving it, returning to the code containing the swi, the mode was
> still 0x10, which is not supervisor mode.  

It sounds like you were already in supervisor mode when you executed the 
SWI; that would corrupt your link register so the return would not happen 
correctly.

However, more details would be needed to be sure.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

Am Mon, 22 Jan 2001 schrieben Sie:
> > Unfortunately the ARM simulator does not support the several 
> > CPU modes, that
> > the ARM7TDMI has. I made a software trap using "swi", and the 
> > pc was set
> > correctly to 0x8. It did also execute the jump instruction 
> > from this place
> > leading to my own swi handler. But when leaving it, returning to the
> > code containing the swi, the mode was still 0x10, which is 
> > not supervisor
> > mode. 
> 
> 
> How do you return from your SWI handler? Don't forget
> you have to make
> 	movs	pc, lr
> to copy SPSR in CPSR at the same time you return, so
> the mode gets changed.
> 
> CPU modes have been in existence since the very beginning
> of the ARM cores, so I doubt it's not supported!
> 
> Cheers,
> Yves

Don´t know what I am doing wrong. This does also not work:
void swi_handler(int reason) {
  switch(reason) {
  case REASON_CHANGE_TO_SV :
    asm volatile ("mrs r0,cpsr": : :"r0");
    asm volatile ("orr r0, r0, #192": : :"r0");
    asm volatile ("msr cpsr, r0");
  default :
    break;
  }
  asm volatile("movs    pc, lr");
}

Could it be that gdb just don´t show the right value?
Jens-Christian

> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[David Korn]

>-----Original Message-----
>From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]

>I am unable to find such a think (which sounds nice) in my version of
>gcc, which i compiled for i960 about a year ago:
>,----------------------------- [ gcc -v ] -----------------------------
>| Reading specs from
>| /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
>| gcc version 2.95.2 19991024 (release)
>`----------------------------------------------------------------------
>2.92.2 shoudn't be sooo old - right?
>
>Is the "sim" option a new feature, a special patch, or something enabled
>for some special cpus?

  Yep.  Sorry, but it's for powerpc only.  The GDB debugger comes with a 
ppc simulator, and the -sim flag compiles code to run with it.  There aren't
simulators for any other cpus.  This is from the "IBM RS/6000 and PowerPC
Options" section of the manual:

----------snip!--------------
-msim 
On embedded PowerPC systems, assume that the startup module is called
`sim-crt0.o' and the standard C libraries are `libsim.a' and `libc.a'. This
is default for `powerpc-*-eabisim' configurations. 
----------snip!--------------

       DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community."


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

In message < 0101231819220B.02452@lab04 >, Jens-Christian Lache writes:
>unknown SWI encountered - 1 - ignoring
>unknown SWI encountered - 2 - ignoring
>unknown SWI encountered - 3 - ignoring
>unknown SWI encountered - 4 - ignoring

It doesn't think you've installed a SWI handler.

>which is initialized by
>
>memPointer = TABLE_ENTRY_SWI_HANDLER_ADDRESS; // 0x20
>*memPointer = (int) swi_wrapper;
>memPointer = JUMP_DESTINATION_SWI; // 0x8
>*memPointer= 0xe59ff010;

Are you certain that this code executes?  How is `memPointer' defined?

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

In message < 01012211514701.02376@lab04 >, Jens-Christian Lache writes:
>Unfortunately the ARM simulator does not support the several CPU modes, that
>the ARM7TDMI has. I made a software trap using "swi", and the pc was set
>correctly to 0x8. It did also execute the jump instruction from this place
>leading to my own swi handler. But when leaving it, returning to the
>code containing the swi, the mode was still 0x10, which is not supervisor
>mode. 

Can you give a concrete example of the code that you think is going wrong?  
The simulator certainly does support different modes - all ARM processors have 
these, not just ARM7TDMI.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

gcc compile

[Sascha Andres]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Well I thought there must be something with the
newlib. But there's no linux or ecos running
on the target. I thought newlib requires a running
os. Is there an optoin to turn this off?

Sascha

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOmvtNGYZ6Od193QxEQIM7gCfSbMLKPcIsi54f2Njs/FwBLQSfTYAn3m7
e7c7oNrGPDeKulHB6Z/XsG5x
=Dljr
-----END PGP SIGNATURE-----


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5864 bytes --]

Hi everybody!

Since a few day´s I try to make software trap´s using "swi" on the ARM
simulator build in gdb. I have tested the code on "real" hardware, it worked
fine. My hardware has a monitor program (angel), which is initializing the
superuser side and switches the proc to user mode before starting the
code at "start" from the crt0.S file.

I still can´t do these sw traps on the simulator. I get:

unknown SWI encountered - 1 - ignoring
unknown SWI encountered - 2 - ignoring
unknown SWI encountered - 3 - ignoring
unknown SWI encountered - 4 - ignoring

for
asm volatile (".equ REASON_CHANGE_TO_SV, 0x0");
asm volatile (".equ REASON_SET_I, 0x1");
asm volatile (".equ REASON_UNSET_I, 0x2");
asm volatile (".equ REASON_SET_F, 0x3");
asm volatile (".equ REASON_UNSET_F, 0x4");
asm volatile ("swi  #REASON_CHANGE_TO_SV");
asm volatile ("swi  #REASON_SET_I");
asm volatile ("swi  #REASON_UNSET_I");
asm volatile ("swi  #REASON_SET_F");

(it does not complain about "swi 0x0", if you may have noticed). I am sure that
it does not enter the function 

Dump of assembler code for function swi_wrapper__Fv:
0x2018ee8 <swi_wrapper__Fv>:	stmdb	sp!, {r0, r1, r2, r3, lr}
0x2018eec <swi_wrapper__Fv+4>:	ldr	r0, [lr, -#4]
0x2018ef0 <swi_wrapper__Fv+8>:	bic	r0, r0, #-16777216	; 0xff000000
0x2018ef4 <swi_wrapper__Fv+12>:	mov	r1, sp
0x2018ef8 <swi_wrapper__Fv+16>:	mrs	r2, SPSR
0x2018efc <swi_wrapper__Fv+20>:	stmdb	sp!, {r2}
0x2018f00 <swi_wrapper__Fv+24>:	bl	0x2018d08 <swi_handler__FiPUi>
0x2018f04 <swi_wrapper__Fv+28>:	ldmia	sp!, {r2}
0x2018f08 <swi_wrapper__Fv+32>:	msr	SPSR_fc, r2
0x2018f0c <swi_wrapper__Fv+36>:	ldmia	sp!, {r0, r1, r2, r3, pc}
End of assembler dump.

which is initialized by

memPointer = TABLE_ENTRY_SWI_HANDLER_ADDRESS; // 0x20
*memPointer = (int) swi_wrapper;
memPointer = JUMP_DESTINATION_SWI; // 0x8
*memPointer= 0xe59ff010;

The swi_wrapper leads to :

void swi_handler(int swi_number, unsigned int * stack ) {
 	38	  static Logger swiLogger((int *) 0x100, (int *) 0x200);  
 	39	  int cpsr;
 	40	
-	41	  switch(swi_number) {
 	42	  case REASON_CHANGE_TO_SV :
-	43	    os->osLogger->log("REASON_CHANGE_TO_SV",0);
-	44	    break;
 	45	  case REASON_SET_I:
-	46	    asm volatile ("mrs r0,cpsr": : :"r0");
-	47	    asm volatile ("orr r0, r0, #128": : :"r0");
-	48	    asm volatile ("msr cpsr, r0");
-	49	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	50	    os->osLogger->log("REASON_SET_I",cpsr);
-	51	    break;
 	52	  case REASON_UNSET_I:
-	53	    asm volatile ("mrs r0,cpsr": : :"r0");
-	54	    asm volatile ("and r0, r0, #0xffff7fff": : :"r0");
-	55	    asm volatile ("msr cpsr, r0");
-	56	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	57	    os->osLogger->log("REASON_UNSET_I",cpsr);
-	58	    break;
 	59	  case REASON_SET_F:
-	60	    asm volatile ("mrs r0,cpsr": : :"r0");
-	61	    asm volatile ("orr r0, r0, #64": : :"r0");
-	62	    asm volatile ("msr cpsr, r0");
-	63	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	64	    os->osLogger->log("REASON_SET_F",cpsr);
-	65	    break;
 	66	  case REASON_UNSET_F:
-	67	    asm volatile ("mrs r0,cpsr": : :"r0");
-	68	    asm volatile ("and r0, r0, #0xffffbfff": : :"r0");
-	69	    asm volatile ("msr cpsr, r0");
-	70	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	71	    os->osLogger->log("REASON_UNSET_F",cpsr);
-	72	    break;
 	73	  default :
-	74	    break;

The logging facility is tested and works fine on the aeb.

Is there still an error in the crt0.S file or could this be a bug of the gdb?
Thank´s for your patience with me :-),
Jens-Christian 
P.S.:
The beginning of the crt0.S file with my modification:

//#include "swi.h"

/* ANSI concatenation macros.  */
#define CONCAT(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b

#ifdef __USER_LABEL_PREFIX__
#define FUNCTION( name ) CONCAT (__USER_LABEL_PREFIX__, name)
#else
#error __USER_LABEL_PREFIX is not defined
#endif

/* .text is used instead of .section .text so it works with arm-aout too.  */
	.text
	.code 32
	.align 	0

	.global	_mainCRTStartup
	.global	_start
	.global	start
start:
_start:
_mainCRTStartup:

/* Start by setting up a stack */
#ifdef ARM_RDP_MONITOR
	/*  Issue Demon SWI to read stack info */
	swi	SWI_GetEnv	/*  Returns command line in r0 */
	mov	sp,r1		/*  and the highest memory address in r1 */
	ldr	sl, .LC2	/*  stack limit is at end of data */
	add	sl, sl, #256	/*  allow slop for stack overflow handling */
				/*  and small frames */
#else
#ifdef ARM_RDI_MONITOR
	/*  Issue Angel SWI to read stack info */
	mov	r0, #AngelSWI_Reason_HeapInfo
	adr	r1, .LC0	/*  point at ptr to 4 words to receive data */
	swi	AngelSWI_ARM	/*  We are always in ARM mode for startup */
	ldr	r0, .LC0	/*  point at values read */
	ldr	sp, [r0, #8]
	ldr	sl, [r0, #12]
	add	sl, sl, #256	/*  allow slop for stack overflow handling */
				/*  and small frames */
#else
	/*  Set up the stack pointer to a fixed value */
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	@	modification, jens-christian
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	@ begin
	// switch to user mode
	.equ MODE_BITS,        0x1F @ all mode bits from cpsr
	.equ USER_MODE,        0x10 @ b10000 is user mode
	
#ifdef TARGET_SIM
	@ initialize the stack pointer
	@ for SV mode
	@ set sp to the end of the RAM (eb01)
	mov	sp, #0x1000

	// switch to user mode
	mrs	r0, cpsr
	bic	r0, r0, #MODE_BITS
	orr	r0, r0, #USER_MODE
	msr	cpsr, r0
#endif //TARGET_SIM

	@ end
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	ldr	r3, .LC0
	mov 	sp, r3
	/* Setup a default stack-limit in-case the code has been

 -- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[David Feustel]

I can't find any 'sim' directory under gcc.
Is 'sim' somewhere else in the tree?

Thanks,

Dave Feustel
Fort Wayne, Indiana
1-219-483-1857

----- Original Message ----- 
From: "Philip Blundell" <philb@gnu.org>
To: "David Korn" <dkorn@pixelpower.com>
Cc: <crossgcc@sources.redhat.com>
Sent: Saturday, January 20, 2001 12:46 PM
Subject: Re: gcc compile 


> >  To the best of my knowledge there is only a ppc target simulator for gdb.
> >I don't know what you are referring to when you say "That=B4s why the code
> >crashes on the simulator"; is it that you have an ARM simulator that is
> >separate from the GNU software, maybe a commercial product?
> 
> This isn't true, in fact.  GDB ships with simulators for several cpus, including 
> ARM.  Take a look in the `sim' subdirectory of the source tree for the full 
> list.
> 
> p.
> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsS="6ribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
> 


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[David Korn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4298 bytes --]

    Hi Jens,

  To the best of my knowledge there is only a ppc target simulator for gdb.
I don't know what you are referring to when you say "That´s why the code
crashes on the simulator"; is it that you have an ARM simulator that is
separate from the GNU software, maybe a commercial product?


         DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anythingo
 ffered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to largen
 umbers of others. This is my contribution to the survival of the online
community." 

>-----Original Message-----
>From: Jens-Christian Lache [ mailto:lache@tu-harburg.de ]
>Sent: 19 January 2001 10:11
>To: David Korn
>Subject: RE: gcc compile
>
>
>Hi! Do you know, what should I do if I want to use target
>simulator in arm-elf-gdb debugger? 
>Normally I use have a monitor program,
>which handles software traps. 
>That´s why the code crashes on the simulator.
>
>Is there s.th. similar to the "sim" option for arm?
>jens-christian
>Am Fre, 19 Jan 2001 schrieben Sie:
>> >-----Original Message-----
>> >From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]
>> 
>> >I am unable to find such a think (which sounds nice) in my 
>version of
>> >gcc, which i compiled for i960 about a year ago:
>> >,----------------------------- [ gcc -v ] 
>-----------------------------
>> >| Reading specs from
>> >| 
>/usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
>> >| gcc version 2.95.2 19991024 (release)
>> 
>>`-------------------------------------------------------------
>---------
>> >2.92.2 shoudn't be sooo old - right?
>> >
>> >Is the "sim" option a new feature, a special patch, or 
>something enabled
>> >for some special cpus?
>> 
>>   Yep.  Sorry, but it's for powerpc only.  The GDB debugger 
>comes with a 
>> ppc simulator, and the -sim flag compiles code to run with 
>it.  There aren't
>> simulators for any other cpus.  This is from the "IBM 
>RS/6000 and PowerPC
>> Options" section of the manual:
>> 
>> ----------snip!--------------
>> -msim 
>> On embedded PowerPC systems, assume that the startup module is called
>> `sim-crt0.o' and the standard C libraries are `libsim.a' and 
>`libc.a'. This
>> is default for `powerpc-*-eabisim' configurations. 
>> ----------snip!--------------
>> 
>>        DaveK
>> -- 
>> The Boulder Pledge: "Under no circumstances will I ever 
>purchase anything 
>> offered to me as the result of an unsolicited email message. 
>Nor will I 
>> forward chain letters, petitions, mass mailings, or virus 
>warnings to large 
>> numbers of others. This is my contribution to the survival 
>of the online
>> community."
>> 
>> 
>> 
>**********************************************************************
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they
>> are addressed. If you have received this email in error please notify
>> the system manager.
>> 
>> This footnote also confirms that this email message has been swept by
>> MIMEsweeper for the presence of computer viruses.
>> 
>> www.mimesweeper.com
>> 
>**********************************************************************
>> 
>> ------
>> Want more information?  See the CrossGCC FAQ, 
> http://www.objsw.com/CrossGCC/
>> Want to unsubscribe? Send a 
>note to crossgcc-unsubscribe@sourceware.cygnus.com
>-- 
>
>
>Jens-Christian Lache
>Technische Universitaet Hamburg-Harburg
>www.tu-harburg.de/~sejl1601
>Mail:
>lache@tu-harburg.de
>lache@ngi.de
>Tel.:
>+0491759610756
>


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

Hey!
Am Sam, 20 Jan 2001 schrieben Sie:
> >  To the best of my knowledge there is only a ppc target simulator for gdb.
> >I don't know what you are referring to when you say "That=B4s why the code
> >crashes on the simulator"; is it that you have an ARM simulator that is
> >separate from the GNU software, maybe a commercial product?
> 
> This isn't true, in fact.  GDB ships with simulators for several cpus, including 
> ARM.  Take a look in the `sim' subdirectory of the source tree for the full 
> list.

Unfortunately the ARM simulator does not support the several CPU modes, that
the ARM7TDMI has. I made a software trap using "swi", and the pc was set
correctly to 0x8. It did also execute the jump instruction from this place
leading to my own swi handler. But when leaving it, returning to the
code containing the swi, the mode was still 0x10, which is not supervisor
mode. 

Jens-Christian



> 
> p.
> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Helmut Kolb]

Hello!

Sorry, if my question fits not exactly on the topic, but...

es klopfte Hua Ji in seine tastatur:
> For testing, you can use gcc -msim...., so that you will no problem for
> creating an executable and can be run with the powerpc-arm-elf-run, which
> should be located in your ./bin directory. 
... i have read a few times about the "-msim" switch of gcc.

I am unable to find such a think (which sounds nice) in my version of
gcc, which i compiled for i960 about a year ago:
,----------------------------- [ gcc -v ] -----------------------------
| Reading specs from
| /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
| gcc version 2.95.2 19991024 (release)
`----------------------------------------------------------------------
2.92.2 shoudn't be sooo old - right?

Is the "sim" option a new feature, a special patch, or something enabled
for some special cpus?
Or is it something completly different?

yours
-- 
Helmut Kolb                              KNAPP Logistik & Automation G.m.b.H.
Kolb.Helmut@knapp.co.at     Guenter-Knapp-Str. 5-7 A-8075 Hart/Graz, Austria
I like cats, but I don't think I could eat a whole one.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Hi! newlib doesn´t need a running os, but you may write your own
linked with it ;-)

jc
Am Mon, 22 Jan 2001 schrieben Sie:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Well I thought there must be something with the
> newlib. But there's no linux or ecos running
> on the target. I thought newlib requires a running
> os. Is there an optoin to turn this off?
> 
> Sascha
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.0
> 
> iQA/AwUBOmvtNGYZ6Od193QxEQIM7gCfSbMLKPcIsi54f2Njs/FwBLQSfTYAn3m7
> e7c7oNrGPDeKulHB6Z/XsG5x
> =Dljr
> -----END PGP SIGNATURE-----
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

In message < 0101231819220B.02452@lab04 >, Jens-Christian Lache writes:
>unknown SWI encountered - 1 - ignoring
>unknown SWI encountered - 2 - ignoring
>unknown SWI encountered - 3 - ignoring
>unknown SWI encountered - 4 - ignoring

It doesn't think you've installed a SWI handler.

>which is initialized by
>
>memPointer = TABLE_ENTRY_SWI_HANDLER_ADDRESS; // 0x20
>*memPointer = (int) swi_wrapper;
>memPointer = JUMP_DESTINATION_SWI; // 0x8
>*memPointer= 0xe59ff010;

Are you certain that this code executes?  How is `memPointer' defined?

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5864 bytes --]

Hi everybody!

Since a few day´s I try to make software trap´s using "swi" on the ARM
simulator build in gdb. I have tested the code on "real" hardware, it worked
fine. My hardware has a monitor program (angel), which is initializing the
superuser side and switches the proc to user mode before starting the
code at "start" from the crt0.S file.

I still can´t do these sw traps on the simulator. I get:

unknown SWI encountered - 1 - ignoring
unknown SWI encountered - 2 - ignoring
unknown SWI encountered - 3 - ignoring
unknown SWI encountered - 4 - ignoring

for
asm volatile (".equ REASON_CHANGE_TO_SV, 0x0");
asm volatile (".equ REASON_SET_I, 0x1");
asm volatile (".equ REASON_UNSET_I, 0x2");
asm volatile (".equ REASON_SET_F, 0x3");
asm volatile (".equ REASON_UNSET_F, 0x4");
asm volatile ("swi  #REASON_CHANGE_TO_SV");
asm volatile ("swi  #REASON_SET_I");
asm volatile ("swi  #REASON_UNSET_I");
asm volatile ("swi  #REASON_SET_F");

(it does not complain about "swi 0x0", if you may have noticed). I am sure that
it does not enter the function 

Dump of assembler code for function swi_wrapper__Fv:
0x2018ee8 <swi_wrapper__Fv>:	stmdb	sp!, {r0, r1, r2, r3, lr}
0x2018eec <swi_wrapper__Fv+4>:	ldr	r0, [lr, -#4]
0x2018ef0 <swi_wrapper__Fv+8>:	bic	r0, r0, #-16777216	; 0xff000000
0x2018ef4 <swi_wrapper__Fv+12>:	mov	r1, sp
0x2018ef8 <swi_wrapper__Fv+16>:	mrs	r2, SPSR
0x2018efc <swi_wrapper__Fv+20>:	stmdb	sp!, {r2}
0x2018f00 <swi_wrapper__Fv+24>:	bl	0x2018d08 <swi_handler__FiPUi>
0x2018f04 <swi_wrapper__Fv+28>:	ldmia	sp!, {r2}
0x2018f08 <swi_wrapper__Fv+32>:	msr	SPSR_fc, r2
0x2018f0c <swi_wrapper__Fv+36>:	ldmia	sp!, {r0, r1, r2, r3, pc}
End of assembler dump.

which is initialized by

memPointer = TABLE_ENTRY_SWI_HANDLER_ADDRESS; // 0x20
*memPointer = (int) swi_wrapper;
memPointer = JUMP_DESTINATION_SWI; // 0x8
*memPointer= 0xe59ff010;

The swi_wrapper leads to :

void swi_handler(int swi_number, unsigned int * stack ) {
 	38	  static Logger swiLogger((int *) 0x100, (int *) 0x200);  
 	39	  int cpsr;
 	40	
-	41	  switch(swi_number) {
 	42	  case REASON_CHANGE_TO_SV :
-	43	    os->osLogger->log("REASON_CHANGE_TO_SV",0);
-	44	    break;
 	45	  case REASON_SET_I:
-	46	    asm volatile ("mrs r0,cpsr": : :"r0");
-	47	    asm volatile ("orr r0, r0, #128": : :"r0");
-	48	    asm volatile ("msr cpsr, r0");
-	49	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	50	    os->osLogger->log("REASON_SET_I",cpsr);
-	51	    break;
 	52	  case REASON_UNSET_I:
-	53	    asm volatile ("mrs r0,cpsr": : :"r0");
-	54	    asm volatile ("and r0, r0, #0xffff7fff": : :"r0");
-	55	    asm volatile ("msr cpsr, r0");
-	56	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	57	    os->osLogger->log("REASON_UNSET_I",cpsr);
-	58	    break;
 	59	  case REASON_SET_F:
-	60	    asm volatile ("mrs r0,cpsr": : :"r0");
-	61	    asm volatile ("orr r0, r0, #64": : :"r0");
-	62	    asm volatile ("msr cpsr, r0");
-	63	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	64	    os->osLogger->log("REASON_SET_F",cpsr);
-	65	    break;
 	66	  case REASON_UNSET_F:
-	67	    asm volatile ("mrs r0,cpsr": : :"r0");
-	68	    asm volatile ("and r0, r0, #0xffffbfff": : :"r0");
-	69	    asm volatile ("msr cpsr, r0");
-	70	    asm volatile ("mrs %0, cpsr":"=r" (cpsr));
-	71	    os->osLogger->log("REASON_UNSET_F",cpsr);
-	72	    break;
 	73	  default :
-	74	    break;

The logging facility is tested and works fine on the aeb.

Is there still an error in the crt0.S file or could this be a bug of the gdb?
Thank´s for your patience with me :-),
Jens-Christian 
P.S.:
The beginning of the crt0.S file with my modification:

//#include "swi.h"

/* ANSI concatenation macros.  */
#define CONCAT(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b

#ifdef __USER_LABEL_PREFIX__
#define FUNCTION( name ) CONCAT (__USER_LABEL_PREFIX__, name)
#else
#error __USER_LABEL_PREFIX is not defined
#endif

/* .text is used instead of .section .text so it works with arm-aout too.  */
	.text
	.code 32
	.align 	0

	.global	_mainCRTStartup
	.global	_start
	.global	start
start:
_start:
_mainCRTStartup:

/* Start by setting up a stack */
#ifdef ARM_RDP_MONITOR
	/*  Issue Demon SWI to read stack info */
	swi	SWI_GetEnv	/*  Returns command line in r0 */
	mov	sp,r1		/*  and the highest memory address in r1 */
	ldr	sl, .LC2	/*  stack limit is at end of data */
	add	sl, sl, #256	/*  allow slop for stack overflow handling */
				/*  and small frames */
#else
#ifdef ARM_RDI_MONITOR
	/*  Issue Angel SWI to read stack info */
	mov	r0, #AngelSWI_Reason_HeapInfo
	adr	r1, .LC0	/*  point at ptr to 4 words to receive data */
	swi	AngelSWI_ARM	/*  We are always in ARM mode for startup */
	ldr	r0, .LC0	/*  point at values read */
	ldr	sp, [r0, #8]
	ldr	sl, [r0, #12]
	add	sl, sl, #256	/*  allow slop for stack overflow handling */
				/*  and small frames */
#else
	/*  Set up the stack pointer to a fixed value */
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	@	modification, jens-christian
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	@ begin
	// switch to user mode
	.equ MODE_BITS,        0x1F @ all mode bits from cpsr
	.equ USER_MODE,        0x10 @ b10000 is user mode
	
#ifdef TARGET_SIM
	@ initialize the stack pointer
	@ for SV mode
	@ set sp to the end of the RAM (eb01)
	mov	sp, #0x1000

	// switch to user mode
	mrs	r0, cpsr
	bic	r0, r0, #MODE_BITS
	orr	r0, r0, #USER_MODE
	msr	cpsr, r0
#endif //TARGET_SIM

	@ end
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	ldr	r3, .LC0
	mov 	sp, r3
	/* Setup a default stack-limit in-case the code has been

 -- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

In message < 200101231017.KAA28604@cam-mail2.cambridge.arm.com >, Richard Earnsha
w writes:
>> You could try `__attribute__ (( interrupt ("SWI")))' with GCC.  This should 
>> suffice for very simple handlers, though you will still need to write in 
>> assembler for anything more sophisticated.
>
>This is new in the CVS version; it wasn't in 2.95.x (at least, if it was, 
>it probably didn't work very well).

Oops, you're right.  It's not in 2.95 at all.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Richard Earnshaw]

> >I don't think you can create a whole swi handler in C (unless
> >gcc has extensions I don't know about. the arm C doesn't
> >anyway).
> 
> You could try `__attribute__ (( interrupt ("SWI")))' with GCC.  This should 
> suffice for very simple handlers, though you will still need to write in 
> assembler for anything more sophisticated.
> 

This is new in the CVS version; it wasn't in 2.95.x (at least, if it was, 
it probably didn't work very well).

R.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

>I don't think you can create a whole swi handler in C (unless
>gcc has extensions I don't know about. the arm C doesn't
>anyway).

You could try `__attribute__ (( interrupt ("SWI")))' with GCC.  This should 
suffice for very simple handlers, though you will still need to write in 
assembler for anything more sophisticated.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Yves Rutschle]

> Even at the beginning of "start" the cpsr is equal to 0x10;
> 
> I have added a mode switch to user mode to crt0.S
> and will install the proposed swi handler.


Aha, good one, I didn't think about that. An ARM core starts
up in SVC (otherwise you can't setup anything). So you need
to switch to usermode indeed.

Probably your hardware initialisation was setting user
mode without your knowing, whereas the simulator only does
what you tell it to do.

Cheers,
Y.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

Hello everybody! The ARM Simulator does support different Modes. I just have
had the wrong arm-elf-gdb in my PATH. It was the last stable version:
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.

Even at the beginning of "start" the cpsr is equal to 0x10;

I have added a mode switch to user mode to crt0.S
and will install the proposed swi handler.

Thank´s a lot,

Jens-Christian



 Am Mon, 22 Jan 2001 schrieben Sie:
> In message < 01012211514701.02376@lab04 >, Jens-Christian Lache writes:
> >Unfortunately the ARM simulator does not support the several CPU modes, that
> >the ARM7TDMI has. I made a software trap using "swi", and the pc was set
> >correctly to 0x8. It did also execute the jump instruction from this place
> >leading to my own swi handler. But when leaving it, returning to the
> >code containing the swi, the mode was still 0x10, which is not supervisor
> >mode. 
> 
> Can you give a concrete example of the code that you think is going wrong?  
> The simulator certainly does support different modes - all ARM processors have 
> these, not just ARM7TDMI.
> 
> p.
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

Am Mon, 22 Jan 2001 schrieben Sie:
> Hallo,
> 
> > I have tested the code on the eb01. After swi the proc is in SV.

Sorry, I wanted to say: I have tested it  on both the sim and the aeb and it
worked  on the aeb but not on the sim.

> 
> Therefore it's not because of the simulator :)
> 
> > 0x2018d28 <swi_handler__Fi>:	mov	r12, sp
> > 0x2018d2c <swi_handler__Fi+4>:	stmdb	sp!, {r11, r12, lr, pc}
> > 0x2018d30 <swi_handler__Fi+8>:	sub	r11, r12, #4	; 0x4
> > 0x2018d34 <swi_handler__Fi+12>:	sub	sp, sp, #12	; 0xc
> [snipped swi routine]
> > 0x2018d98 <swi_handler__Fi+112>:	ldmdb	r11, {r11, sp, pc}
> 
> This code won't set CPSR back to SPSR; Try to add a hat
> at the end of the return instruction:
> 	ldmdb r11, {r11, sp, pc}^
> (the hat activates the copy of SPSR to CPSR same as movs pc,lr)
> 
> >Don?t know what I am doing wrong. This does also not work:
> >void swi_handler(int reason) {
> >  switch(reason) {
> >  case REASON_CHANGE_TO_SV :
> >    asm volatile ("mrs r0,cpsr": : :"r0");
> >    asm volatile ("orr r0, r0, #192": : :"r0");
> >    asm volatile ("msr cpsr, r0");
> >  default :
> >    break;
> >  }
> >  asm volatile("movs    pc, lr");
> >}
> 
> Huh. What do you think happens to the stack when you leave
> like that? :-) (hint: you pushed 4 registers when entering
> the routine...)
> 
> I don't think you can create a whole swi handler in C (unless
> gcc has extensions I don't know about. the arm C doesn't
> anyway).
> 
> I'd advise you to use an assembly top-level handler such
> as:
> 
> 	stmdf sp!, {r0-r3, lr}
> 	ldr	r0, [lr,#-4]
> 	bic	r0, r0, #0xff000000
> 	mov	r1, sp			; r1 = SWI number
> 	mrs	r2, spsr
> 	stmfd	sp!, {r2}			; keep spsr in case of nested swi's
> 	bl	C_Handler
> 	ldmfd	sp!, {r2}
> 	msr	spsr, r2			; restore spsr
> 	ldmfd	sp!, {r0-r3, pc}^		; return, restore cpsr from spsr
> 
> (this is straight from ADS' developer guide, by the way)
> 
> Then your C handler looks like:
> 
> void C_Handler( int swi_number, unsigned int * stack )
> {
>     printf( "got swi %d\n", swi_number );
> }
> 
> Hope that helps!
 Me too! :-)
I will try it!

Jens-Christian

> 
> Yves.
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

ok, I forgot to include the linker script. The makefile should be more common
now, please adjust 
TOOLDIR=/home/hiwi/lache/tools
and 
CC=$(TOOLDIR)/bin/arm-elf-gcc
to the appropriate values.

Thank you for looking at the code!

Jens-Christian


 Am Mon, 22 Jan 2001 schrieben Sie:
> > Unfortunately the ARM simulator does not support the several 
> > CPU modes, that
> > the ARM7TDMI has. I made a software trap using "swi", and the 
> > pc was set
> > correctly to 0x8. It did also execute the jump instruction 
> > from this place
> > leading to my own swi handler. But when leaving it, returning to the
> > code containing the swi, the mode was still 0x10, which is 
> > not supervisor
> > mode. 
> 
> 
> How do you return from your SWI handler? Don't forget
> you have to make
> 	movs	pc, lr
> to copy SPSR in CPSR at the same time you return, so
> the mode gets changed.
> 
> CPU modes have been in existence since the very beginning
> of the ARM cores, so I doubt it's not supported!
> 
> Cheers,
> Yves
> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

[-- Attachment #2: adeos.tgz --]
[-- Type: application/x-gzip, Size: 13816 bytes --]

RE: gcc compile

[Yves Rutschle]

Hallo,

> I have tested the code on the eb01. After swi the proc is in SV.

Therefore it's not because of the simulator :)

> 0x2018d28 <swi_handler__Fi>:	mov	r12, sp
> 0x2018d2c <swi_handler__Fi+4>:	stmdb	sp!, {r11, r12, lr, pc}
> 0x2018d30 <swi_handler__Fi+8>:	sub	r11, r12, #4	; 0x4
> 0x2018d34 <swi_handler__Fi+12>:	sub	sp, sp, #12	; 0xc
[snipped swi routine]
> 0x2018d98 <swi_handler__Fi+112>:	ldmdb	r11, {r11, sp, pc}

This code won't set CPSR back to SPSR; Try to add a hat
at the end of the return instruction:
	ldmdb r11, {r11, sp, pc}^
(the hat activates the copy of SPSR to CPSR same as movs pc,lr)

>Don?t know what I am doing wrong. This does also not work:
>void swi_handler(int reason) {
>  switch(reason) {
>  case REASON_CHANGE_TO_SV :
>    asm volatile ("mrs r0,cpsr": : :"r0");
>    asm volatile ("orr r0, r0, #192": : :"r0");
>    asm volatile ("msr cpsr, r0");
>  default :
>    break;
>  }
>  asm volatile("movs    pc, lr");
>}

Huh. What do you think happens to the stack when you leave
like that? :-) (hint: you pushed 4 registers when entering
the routine...)

I don't think you can create a whole swi handler in C (unless
gcc has extensions I don't know about. the arm C doesn't
anyway).

I'd advise you to use an assembly top-level handler such
as:

	stmdf sp!, {r0-r3, lr}
	ldr	r0, [lr,#-4]
	bic	r0, r0, #0xff000000
	mov	r1, sp			; r1 = SWI number
	mrs	r2, spsr
	stmfd	sp!, {r2}			; keep spsr in case of nested swi's
	bl	C_Handler
	ldmfd	sp!, {r2}
	msr	spsr, r2			; restore spsr
	ldmfd	sp!, {r0-r3, pc}^		; return, restore cpsr from spsr

(this is straight from ADS' developer guide, by the way)

Then your C handler looks like:

void C_Handler( int swi_number, unsigned int * stack )
{
    printf( "got swi %d\n", swi_number );
}

Hope that helps!

Yves.






------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

Am Mon, 22 Jan 2001 schrieben Sie:
> > Unfortunately the ARM simulator does not support the several 
> > CPU modes, that
> > the ARM7TDMI has. I made a software trap using "swi", and the 
> > pc was set
> > correctly to 0x8. It did also execute the jump instruction 
> > from this place
> > leading to my own swi handler. But when leaving it, returning to the
> > code containing the swi, the mode was still 0x10, which is 
> > not supervisor
> > mode. 
> 
> 
> How do you return from your SWI handler? Don't forget
> you have to make
> 	movs	pc, lr
> to copy SPSR in CPSR at the same time you return, so
> the mode gets changed.
> 
> CPU modes have been in existence since the very beginning
> of the ARM cores, so I doubt it's not supported!
> 
> Cheers,
> Yves

Don´t know what I am doing wrong. This does also not work:
void swi_handler(int reason) {
  switch(reason) {
  case REASON_CHANGE_TO_SV :
    asm volatile ("mrs r0,cpsr": : :"r0");
    asm volatile ("orr r0, r0, #192": : :"r0");
    asm volatile ("msr cpsr, r0");
  default :
    break;
  }
  asm volatile("movs    pc, lr");
}

Could it be that gdb just don´t show the right value?
Jens-Christian

> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

Am Mon, 22 Jan 2001 schrieben Sie:
> > Unfortunately the ARM simulator does not support the several 
> > CPU modes, that
> > the ARM7TDMI has. I made a software trap using "swi", and the 
> > pc was set
> > correctly to 0x8. It did also execute the jump instruction 
> > from this place
> > leading to my own swi handler. But when leaving it, returning to the
> > code containing the swi, the mode was still 0x10, which is 
> > not supervisor
> > mode. 
> 
> 
> How do you return from your SWI handler? Don't forget
> you have to make
> 	movs	pc, lr
> to copy SPSR in CPSR at the same time you return, so
> the mode gets changed.
> 
> CPU modes have been in existence since the very beginning
> of the ARM cores, so I doubt it's not supported!
> 
> Cheers,
> Yves
Hello!
This is how the swi_handler looks like. You may have a look at the source code.
Please say make and run it on the gdb sim. In my opinion it wasn´t in SV.
I have tested the code on the eb01. After swi the proc is in SV.


Thank you all for your help!!!

Jens-Christian

0x2018d28 <swi_handler__Fi>:	mov	r12, sp
0x2018d2c <swi_handler__Fi+4>:	stmdb	sp!, {r11, r12, lr, pc}
0x2018d30 <swi_handler__Fi+8>:	sub	r11, r12, #4	; 0x4
0x2018d34 <swi_handler__Fi+12>:	sub	sp, sp, #12	; 0xc
0x2018d38 <swi_handler__Fi+16>:	str	r0, [r11, -#16]
0x2018d3c <swi_handler__Fi+20>:	mov	r3, #68	; 0x44
0x2018d40 <swi_handler__Fi+24>:	str	r3, [r11, -#20]
0x2018d44 <swi_handler__Fi+28>:	ldr	r3, [r11, -#16]
0x2018d48 <swi_handler__Fi+32>:	cmp	r3, #1	; 0x1
0x2018d4c <swi_handler__Fi+36>:	beq	0x2018d54 <swi_handler__Fi+44>
0x2018d50 <swi_handler__Fi+40>:	b	0x2018d8c <swi_handler__Fi+100>
0x2018d54 <swi_handler__Fi+44>:	mrs	r0, cpsr
0x2018d58 <swi_handler__Fi+48>:	orr	r0, r0, #192	; 0xc0
0x2018d5c <swi_handler__Fi+52>:	msr	cpsr_all, r0
0x2018d60 <swi_handler__Fi+56>:	mrs	r3, cpsr
0x2018d64 <swi_handler__Fi+60>:	str	r3, [r11, -#24]
0x2018d68 <swi_handler__Fi+64>:	ldr	r3, [r11, -#20]
0x2018d6c <swi_handler__Fi+68>:	ldr	r2, [r11, -#24]
0x2018d70 <swi_handler__Fi+72>:	str	r2, [r3]
0x2018d74 <swi_handler__Fi+76>:	mvn	r3, #65280	; 0xff00
0x2018d78 <swi_handler__Fi+80>:	sub	r3, r3, #207	; 0xcf
0x2018d7c <swi_handler__Fi+84>:	str	r3, [r11, -#20]
0x2018d80 <swi_handler__Fi+88>:	ldr	r3, [r11, -#20]
0x2018d84 <swi_handler__Fi+92>:	mov	r2, #22	; 0x16
0x2018d88 <swi_handler__Fi+96>:	str	r2, [r3]
0x2018d8c <swi_handler__Fi+100>:	b	0x2018d90 <swi_handler__Fi+104>
0x2018d90 <swi_handler__Fi+104>:	b	0x2018d98 <swi_handler__Fi+112>
0x2018d94 <swi_handler__Fi+108>:	b	0x2018d98 <swi_handler__Fi+112>
0x2018d98 <swi_handler__Fi+112>:	ldmdb	r11, {r11, sp, pc}


> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

[-- Attachment #2: adeos.tgz --]
[-- Type: application/x-gzip, Size: 11878 bytes --]

RE: gcc compile

[Yves Rutschle]

> Unfortunately the ARM simulator does not support the several 
> CPU modes, that
> the ARM7TDMI has. I made a software trap using "swi", and the 
> pc was set
> correctly to 0x8. It did also execute the jump instruction 
> from this place
> leading to my own swi handler. But when leaving it, returning to the
> code containing the swi, the mode was still 0x10, which is 
> not supervisor
> mode. 


How do you return from your SWI handler? Don't forget
you have to make
	movs	pc, lr
to copy SPSR in CPSR at the same time you return, so
the mode gets changed.

CPU modes have been in existence since the very beginning
of the ARM cores, so I doubt it's not supported!

Cheers,
Yves



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Richard Earnshaw]

lache@tu-harburg.de said:
> Unfortunately the ARM simulator does not support the several CPU
> modes, that the ARM7TDMI has. I made a software trap using "swi", and
> the pc was set correctly to 0x8. It did also execute the jump
> instruction from this place leading to my own swi handler. But when
> leaving it, returning to the code containing the swi, the mode was
> still 0x10, which is not supervisor mode.  

It sounds like you were already in supervisor mode when you executed the 
SWI; that would corrupt your link register so the return would not happen 
correctly.

However, more details would be needed to be sure.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

In message < 01012211514701.02376@lab04 >, Jens-Christian Lache writes:
>Unfortunately the ARM simulator does not support the several CPU modes, that
>the ARM7TDMI has. I made a software trap using "swi", and the pc was set
>correctly to 0x8. It did also execute the jump instruction from this place
>leading to my own swi handler. But when leaving it, returning to the
>code containing the swi, the mode was still 0x10, which is not supervisor
>mode. 

Can you give a concrete example of the code that you think is going wrong?  
The simulator certainly does support different modes - all ARM processors have 
these, not just ARM7TDMI.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

Hey!
Am Sam, 20 Jan 2001 schrieben Sie:
> >  To the best of my knowledge there is only a ppc target simulator for gdb.
> >I don't know what you are referring to when you say "That=B4s why the code
> >crashes on the simulator"; is it that you have an ARM simulator that is
> >separate from the GNU software, maybe a commercial product?
> 
> This isn't true, in fact.  GDB ships with simulators for several cpus, including 
> ARM.  Take a look in the `sim' subdirectory of the source tree for the full 
> list.

Unfortunately the ARM simulator does not support the several CPU modes, that
the ARM7TDMI has. I made a software trap using "swi", and the pc was set
correctly to 0x8. It did also execute the jump instruction from this place
leading to my own swi handler. But when leaving it, returning to the
code containing the swi, the mode was still 0x10, which is not supervisor
mode. 

Jens-Christian



> 
> p.
> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Hi! newlib doesn´t need a running os, but you may write your own
linked with it ;-)

jc
Am Mon, 22 Jan 2001 schrieben Sie:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Well I thought there must be something with the
> newlib. But there's no linux or ecos running
> on the target. I thought newlib requires a running
> os. Is there an optoin to turn this off?
> 
> Sascha
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.0
> 
> iQA/AwUBOmvtNGYZ6Od193QxEQIM7gCfSbMLKPcIsi54f2Njs/FwBLQSfTYAn3m7
> e7c7oNrGPDeKulHB6Z/XsG5x
> =Dljr
> -----END PGP SIGNATURE-----
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

gcc compile

[Sascha Andres]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Well I thought there must be something with the
newlib. But there's no linux or ecos running
on the target. I thought newlib requires a running
os. Is there an optoin to turn this off?

Sascha

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOmvtNGYZ6Od193QxEQIM7gCfSbMLKPcIsi54f2Njs/FwBLQSfTYAn3m7
e7c7oNrGPDeKulHB6Z/XsG5x
=Dljr
-----END PGP SIGNATURE-----


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

>I can't find any 'sim' directory under gcc.
>Is 'sim' somewhere else in the tree?

It's bundled with GDB, not GCC.  I imagine it's included in the gdb-5.0 
tarball.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[David Feustel]

I can't find any 'sim' directory under gcc.
Is 'sim' somewhere else in the tree?

Thanks,

Dave Feustel
Fort Wayne, Indiana
1-219-483-1857

----- Original Message ----- 
From: "Philip Blundell" <philb@gnu.org>
To: "David Korn" <dkorn@pixelpower.com>
Cc: <crossgcc@sources.redhat.com>
Sent: Saturday, January 20, 2001 12:46 PM
Subject: Re: gcc compile 


> >  To the best of my knowledge there is only a ppc target simulator for gdb.
> >I don't know what you are referring to when you say "That=B4s why the code
> >crashes on the simulator"; is it that you have an ARM simulator that is
> >separate from the GNU software, maybe a commercial product?
> 
> This isn't true, in fact.  GDB ships with simulators for several cpus, including 
> ARM.  Take a look in the `sim' subdirectory of the source tree for the full 
> list.
> 
> p.
> 
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsS="6ribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
> 


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Philip Blundell]

>  To the best of my knowledge there is only a ppc target simulator for gdb.
>I don't know what you are referring to when you say "That=B4s why the code
>crashes on the simulator"; is it that you have an ARM simulator that is
>separate from the GNU software, maybe a commercial product?

This isn't true, in fact.  GDB ships with simulators for several cpus, including 
ARM.  Take a look in the `sim' subdirectory of the source tree for the full 
list.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Kai Ruottu]

Helmut Kolb wrote:
> 
> es klopfte Hua Ji in seine tastatur:
> > For testing, you can use gcc -msim...., so that you will no problem for
> > creating an executable and can be run with the powerpc-arm-elf-run, which
> > should be located in your ./bin directory.
>
> ... i have read a few times about the "-msim" switch of gcc.
> 
> I am unable to find such a think (which sounds nice) in my version of
> gcc, which i compiled for i960 about a year ago:
> ,----------------------------- [ gcc -v ] -----------------------------
> | Reading specs from
> | /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
> | gcc version 2.95.2 19991024 (release)
> `----------------------------------------------------------------------
> 2.92.2 shoudn't be sooo old - right?
> 
> Is the "sim" option a new feature, a special patch, or something enabled
> for some special cpus?

 The option is available probably only for PowerPC, I don't remember it used
elsewhere.

 The 'i960-coff' target uses the 'mon960' as the only available target (in newlib)
and the i960-simulator in GDB seems to simulate it. Ok, here is a clip from my
'specs' for 'i960-coff':

------------------------ clip ------------------------------------------
*endfile:


*link:
%{mka:-AKA}%{mkb:-AKB}%{msa:-ASA}%{msb:-ASB} %{mmc:-AMC}%{mca:-ACA}%{mcc:-ACC}%{mcf:-ACF}
%{mja:-AJX}%{mjd:-AJX}%{mjf:-AJX}%{mrp:-AJX} %{mbout:-Fbout}%{mcoff:-Fcoff} %{mlink-relax:-relax} -T mon960.ld%s

*lib:
-lc -lmon960 -lgcc -lc

*libgcc:


*startfile:
crt0%O%s
------------------------ clip ------------------------------------------

 If I compile the C program for the default 'mon960' and use the '-mka'
(I remember the KA being the only supported model in the simulator) :

e:\usr\local\samples>gcc-i960-coff -mka -g -o tst_i960ka.gx tprintf.c

and then try it with the standalone simulator (from GDB), it runs without
any problems (even under Win32...) :

e:\usr\local\samples>run-i960-coff-mw tst_i960ka.gx
%.4x:   `0012'
%04x:   `0012'
%4.4x:  `0012'
%04.4x: `0012'
%4.3x:  ` 012'
%04.3x: ` 012'
%.*x:   `0012'
%0*x:   `0012'
%*.*x:  `0012'
%0*.*x: `0012'
bad format:     "z"
nil pointer (padded):   "       0x0"
decimal negative:       "-2345"
octal negative: "37777773327"
hex negative:   "fffff6d7"
long decimal number:    "-123456"
long octal negative:    "37777773327"
long unsigned decimal number:   "4294843840"
zero-padded LDN:        "-000123456"
< snip >

 Hopefully this was your problem and can help you to solve it...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5908 bytes --]

Am Fre, 19 Jan 2001 schrieben Sie:
> Hi Jens,
> 
>   To the best of my knowledge there is only a ppc target simulator for gdb.
> I don't know what you are referring to when you say "That´s why the code
> crashes on the simulator"; is it that you have an ARM simulator that is
> separate from the GNU software, maybe a commercial product?

It is build in the arm-elf-gdb, so it´s free. The simulator may come 
from Berkely university, but I am not sure. I compiled newlib
with 
newlib_cflags="${newlib_cflags} -DARM_RDI_MONITOR"
turned off in configure.host. It still does make a call to angel
while doing 
pStack     = new int[stackSize];
in "libcfunc.c" , abort:

-	0x201c864	<abort>:		mov	r12, sp
-	0x201c868	<abort+4>:		stmdb	sp!, {r11, r12, lr, pc}
-	0x201c86c	<abort+8>:		sub	r11, r12, #4	; 0x4
-	0x201c870	<abort+12>:		mov	r3, #131072	; 0x20000
-	0x201c874	<abort+16>:		add	r3, r3, #34	; 0x22
-	0x201c878	<abort+20>:		mov	r2, #24	; 0x18
-	0x201c87c	<abort+24>:		mov	r0, r2
-	0x201c880	<abort+28>:		mov	r1, r3
-	0x201c884	<abort+32>:		swi	0x00123456
-	0x201c888	<abort+36>:		mov	r2, r0
-	0x201c88c	<abort+40>:		ldmdb	r11, {r11, sp, pc}

(Can anybody have a look at the compiling output? Couldn´t find "rdi" or "angel"
in it anymore)

At the moment, I write my own memory allocator. I want to disable my monitor
program on the target in the final version of the RTOS that I am porting at the
moment. I still hope just to use new int[stackSize]; , leaving the "dirty work"
to newlib.

Jens-Christian

> 
> 
>          DaveK
> -- 
> The Boulder Pledge: "Under no circumstances will I ever purchase anythingo
>  ffered to me as the result of an unsolicited email message. Nor will I 
> forward chain letters, petitions, mass mailings, or virus warnings to largen
>  umbers of others. This is my contribution to the survival of the online
> community." 
> 
> >-----Original Message-----
> >From: Jens-Christian Lache [ mailto:lache@tu-harburg.de ]
> >Sent: 19 January 2001 10:11
> >To: David Korn
> >Subject: RE: gcc compile
> >
> >
> >Hi! Do you know, what should I do if I want to use target
> >simulator in arm-elf-gdb debugger? 
> >Normally I use have a monitor program,
> >which handles software traps. 
> >That´s why the code crashes on the simulator.
> >
> >Is there s.th. similar to the "sim" option for arm?
> >jens-christian
> >Am Fre, 19 Jan 2001 schrieben Sie:
> >> >-----Original Message-----
> >> >From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]
> >> 
> >> >I am unable to find such a think (which sounds nice) in my 
> >version of
> >> >gcc, which i compiled for i960 about a year ago:
> >> >,----------------------------- [ gcc -v ] 
> >-----------------------------
> >> >| Reading specs from
> >> >| 
> >/usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
> >> >| gcc version 2.95.2 19991024 (release)
> >> 
> >>`-------------------------------------------------------------
> >---------
> >> >2.92.2 shoudn't be sooo old - right?
> >> >
> >> >Is the "sim" option a new feature, a special patch, or 
> >something enabled
> >> >for some special cpus?
> >> 
> >>   Yep.  Sorry, but it's for powerpc only.  The GDB debugger 
> >comes with a 
> >> ppc simulator, and the -sim flag compiles code to run with 
> >it.  There aren't
> >> simulators for any other cpus.  This is from the "IBM 
> >RS/6000 and PowerPC
> >> Options" section of the manual:
> >> 
> >> ----------snip!--------------
> >> -msim 
> >> On embedded PowerPC systems, assume that the startup module is called
> >> `sim-crt0.o' and the standard C libraries are `libsim.a' and 
> >`libc.a'. This
> >> is default for `powerpc-*-eabisim' configurations. 
> >> ----------snip!--------------
> >> 
> >>        DaveK
> >> -- 
> >> The Boulder Pledge: "Under no circumstances will I ever 
> >purchase anything 
> >> offered to me as the result of an unsolicited email message. 
> >Nor will I 
> >> forward chain letters, petitions, mass mailings, or virus 
> >warnings to large 
> >> numbers of others. This is my contribution to the survival 
> >of the online
> >> community."
> >> 
> >> 
> >> 
> >**********************************************************************
> >> This email and any files transmitted with it are confidential and
> >> intended solely for the use of the individual or entity to whom they
> >> are addressed. If you have received this email in error please notify
> >> the system manager.
> >> 
> >> This footnote also confirms that this email message has been swept by
> >> MIMEsweeper for the presence of computer viruses.
> >> 
> >> www.mimesweeper.com
> >> 
> >**********************************************************************
> >> 
> >> ------
> >> Want more information?  See the CrossGCC FAQ, 
> > http://www.objsw.com/CrossGCC/
> >> Want to unsubscribe? Send a 
> >note to crossgcc-unsubscribe@sourceware.cygnus.com
> >-- 
> >
> >
> >Jens-Christian Lache
> >Technische Universitaet Hamburg-Harburg
> >www.tu-harburg.de/~sejl1601
> >Mail:
> >lache@tu-harburg.de
> >lache@ngi.de
> >Tel.:
> >+0491759610756
> >
> 
> 
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> www.mimesweeper.com
> **********************************************************************
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[David Korn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4298 bytes --]

    Hi Jens,

  To the best of my knowledge there is only a ppc target simulator for gdb.
I don't know what you are referring to when you say "That´s why the code
crashes on the simulator"; is it that you have an ARM simulator that is
separate from the GNU software, maybe a commercial product?


         DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anythingo
 ffered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to largen
 umbers of others. This is my contribution to the survival of the online
community." 

>-----Original Message-----
>From: Jens-Christian Lache [ mailto:lache@tu-harburg.de ]
>Sent: 19 January 2001 10:11
>To: David Korn
>Subject: RE: gcc compile
>
>
>Hi! Do you know, what should I do if I want to use target
>simulator in arm-elf-gdb debugger? 
>Normally I use have a monitor program,
>which handles software traps. 
>That´s why the code crashes on the simulator.
>
>Is there s.th. similar to the "sim" option for arm?
>jens-christian
>Am Fre, 19 Jan 2001 schrieben Sie:
>> >-----Original Message-----
>> >From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]
>> 
>> >I am unable to find such a think (which sounds nice) in my 
>version of
>> >gcc, which i compiled for i960 about a year ago:
>> >,----------------------------- [ gcc -v ] 
>-----------------------------
>> >| Reading specs from
>> >| 
>/usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
>> >| gcc version 2.95.2 19991024 (release)
>> 
>>`-------------------------------------------------------------
>---------
>> >2.92.2 shoudn't be sooo old - right?
>> >
>> >Is the "sim" option a new feature, a special patch, or 
>something enabled
>> >for some special cpus?
>> 
>>   Yep.  Sorry, but it's for powerpc only.  The GDB debugger 
>comes with a 
>> ppc simulator, and the -sim flag compiles code to run with 
>it.  There aren't
>> simulators for any other cpus.  This is from the "IBM 
>RS/6000 and PowerPC
>> Options" section of the manual:
>> 
>> ----------snip!--------------
>> -msim 
>> On embedded PowerPC systems, assume that the startup module is called
>> `sim-crt0.o' and the standard C libraries are `libsim.a' and 
>`libc.a'. This
>> is default for `powerpc-*-eabisim' configurations. 
>> ----------snip!--------------
>> 
>>        DaveK
>> -- 
>> The Boulder Pledge: "Under no circumstances will I ever 
>purchase anything 
>> offered to me as the result of an unsolicited email message. 
>Nor will I 
>> forward chain letters, petitions, mass mailings, or virus 
>warnings to large 
>> numbers of others. This is my contribution to the survival 
>of the online
>> community."
>> 
>> 
>> 
>**********************************************************************
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they
>> are addressed. If you have received this email in error please notify
>> the system manager.
>> 
>> This footnote also confirms that this email message has been swept by
>> MIMEsweeper for the presence of computer viruses.
>> 
>> www.mimesweeper.com
>> 
>**********************************************************************
>> 
>> ------
>> Want more information?  See the CrossGCC FAQ, 
> http://www.objsw.com/CrossGCC/
>> Want to unsubscribe? Send a 
>note to crossgcc-unsubscribe@sourceware.cygnus.com
>-- 
>
>
>Jens-Christian Lache
>Technische Universitaet Hamburg-Harburg
>www.tu-harburg.de/~sejl1601
>Mail:
>lache@tu-harburg.de
>lache@ngi.de
>Tel.:
>+0491759610756
>


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[David Korn]

>-----Original Message-----
>From: Helmut Kolb [ mailto:Helmut.Kolb@knapp.com ]

>I am unable to find such a think (which sounds nice) in my version of
>gcc, which i compiled for i960 about a year ago:
>,----------------------------- [ gcc -v ] -----------------------------
>| Reading specs from
>| /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
>| gcc version 2.95.2 19991024 (release)
>`----------------------------------------------------------------------
>2.92.2 shoudn't be sooo old - right?
>
>Is the "sim" option a new feature, a special patch, or something enabled
>for some special cpus?

  Yep.  Sorry, but it's for powerpc only.  The GDB debugger comes with a 
ppc simulator, and the -sim flag compiles code to run with it.  There aren't
simulators for any other cpus.  This is from the "IBM RS/6000 and PowerPC
Options" section of the manual:

----------snip!--------------
-msim 
On embedded PowerPC systems, assume that the startup module is called
`sim-crt0.o' and the standard C libraries are `libsim.a' and `libc.a'. This
is default for `powerpc-*-eabisim' configurations. 
----------snip!--------------

       DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community."


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Helmut Kolb]

Hello!

Sorry, if my question fits not exactly on the topic, but...

es klopfte Hua Ji in seine tastatur:
> For testing, you can use gcc -msim...., so that you will no problem for
> creating an executable and can be run with the powerpc-arm-elf-run, which
> should be located in your ./bin directory. 
... i have read a few times about the "-msim" switch of gcc.

I am unable to find such a think (which sounds nice) in my version of
gcc, which i compiled for i960 about a year ago:
,----------------------------- [ gcc -v ] -----------------------------
| Reading specs from
| /usr/local/i960/compiler/lib/gcc-lib/i960-unknown-coff/2.95.2/specs
| gcc version 2.95.2 19991024 (release)
`----------------------------------------------------------------------
2.92.2 shoudn't be sooo old - right?

Is the "sim" option a new feature, a special patch, or something enabled
for some special cpus?
Or is it something completly different?

yours
-- 
Helmut Kolb                              KNAPP Logistik & Automation G.m.b.H.
Kolb.Helmut@knapp.co.at     Guenter-Knapp-Str. 5-7 A-8075 Hart/Graz, Austria
I like cats, but I don't think I could eat a whole one.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: gcc compile

[Hua Ji]

 

Sascha Andres schrieb:
> hi,
> i've build the gcc with the following command line:
> 
> there is no crt0.o for arm-elf in the/tools dir.
> so how to compile the missing file(s) ?

>You need to build a cross-newlib too?

Hua: I guess this is no special related to newlib, but with that he didn't
explicitely specify an target OS. With arm-elf configurations, system will
not **AUTOMATICALLY* go for the __start symbol and other part, which is used
for initialization before cpu gives control to __main entry. 

My (personal) suggestion is: This is not a error. Leave it, if you are doing
your coding for the raw board without any os support(like linux).

For testing, you can use gcc -msim...., so that you will no problem for
creating an executable and can be run with the powerpc-arm-elf-run, which
should be located in your ./bin directory. 

For real development, sure we need provide a start.S in which the __start
entry will be provided. So that our codes can be deploed onto the RAW board.

Wish I am correct(keep my fingers crossed). However, folks, do point out if
I am wrong. I just wish we can grow together!

Hua

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Gerrit Peter Haase]

Sascha Andres schrieb:
> hi,
> i've build the gcc with the following command line:
> 
> there is no crt0.o for arm-elf in the/tools dir.
> so how to compile the missing file(s) ?

You need to build a cross-newlib too?

-- 
Gerrit

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gcc compile

[Jonathan Larmour]

Sascha Andres wrote:
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> hi,
> i've build the gcc with the following command line:
> 
> /src/gcc/gcc-2.95.2/configure --target=arm-elf \
>     --prefix=/tools \
>     --exec-prefix=/tools/H-i686-pc-linux-gnu \
>     --with-gnu-as --with-gnu-ld --with-newlib \
>     --nfp \
>    -v 2>&1 | tee configure.out
> make -w all-gcc install-gcc \
>     LANGUAGES="c c++" 2>&1 | tee make.out
> 
> the binutils are build without any errors and this
> runs through too. but when compiling a simple c file
> i get the message
> 
> 'crt0.o not found.'.
> 
> there is no crt0.o for arm-elf in the/tools dir.
> so how to compile the missing file(s) ?

You need to build newlib for your target. Read the crossgcc FAQ (see the
end of this message).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

gcc compile

[Sascha Andres]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,
i've build the gcc with the following command line:

/src/gcc/gcc-2.95.2/configure --target=arm-elf \
    --prefix=/tools \
    --exec-prefix=/tools/H-i686-pc-linux-gnu \
    --with-gnu-as --with-gnu-ld --with-newlib \
    --nfp \
   -v 2>&1 | tee configure.out
make -w all-gcc install-gcc \
    LANGUAGES="c c++" 2>&1 | tee make.out

the binutils are build without any errors and this
runs through too. but when compiling a simple c file
i get the message

'crt0.o not found.'.

there is no crt0.o for arm-elf in the/tools dir.
so how to compile the missing file(s) ?

sascha

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOmcmlGYZ6Od193QxEQIMPgCePNq7BgEFW2m187DO3GPUnPkaksQAoOYw
Kz1bxqZv/56OW487RAvpW1DL
=yi3a
-----END PGP SIGNATURE-----


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com