This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: arm-wince-pe: output problem w/GCC 3.2


Kai:

First off, thank you for your detailed and thoughtful response.  We really
do appreciate it..

> Quickly seen the FSF-gcc-3.x-sources DON'T support 'arm-wince-pe' at
> all, only the 'generic' 'arm-pe' (do any embedded people use this?)
> and the 'arm-epoc-pe'. There are other gcc-3.x sources with the 
> 'support' (at least it looks so...) though...  So, what extra was
> done in order to add the needed ARM/WinCE support ? 

This is not our understanding although we may be wrong.  I was able
to configure and build gcc with:

% configure --target=arm-wince-pe --prefix=/usr/local/wince \
--enable-languages="c,c++" --with-headers=$basedir/wce300/inc \
--enable-multilib=no

I have been using an unpatched, generic download of gcc-3.2 to do this.
The only thing I've had to change is to make a few very minor alterations
to libgcc2.c to deal with unresolved symbols at link time (for my
test program!!).  But on my RedHat 7.1 x86 machine, this configuration
is accepted and I'm able to run the subsequent build of GCC to completion.

Of course, it may be that the GCC configuration process accepts this
target specification but does not produce anything useful from it.
According to several people though, (e.g. Nick Clifton) this should
be a (at least partially) supported configuration.

I am using binutils-2.13, unpatched also, and configuring it with

% configure --target=$target --prefix=/usr/local/wince

>> Presumably the startup code or something else is wrong, but I am
>> unsure what I should do next.

> I have only the WinCE2.0 libs for MIPS and SH (and for the x86-emu),
> and they had no separate 'startups' ('crt*.obj' or something), only
> the libraries ('*.lib'). Does the WinCE3.0-stuff have some separate
> startup files?

Not that I can see.

> Which startups and libs you linked against when creating the
> executable?  In the MIPS and SH cases the 'coredll.lib' and
> 'corelibc.lib' seemed to be the basic C-libraries and one of
> these had the C-startups included.

To create an .exe with M$ Embedded Visual C++ compiler, the link for a
(WORKING) simple "Hello World" type program looks as follows for WinCE 3.0:

link /subsystem:windowsce,3.00 /entry:mainACRTStartup /base:0x00010000 \
/stack:0x10000,0x1000 /align:4096 /machine:ARM -OUT:hello.exe -pdb:none \
hello.o -nodefaultlib:oldnames.lib -nodefaultlib:libc.lib corelibc.lib \
coredll.lib

So it's M$ corelibc.dll and coredll.dll that are being linked against,
and the entry point appears to be mainACRTStartup, which resides in
corelibc.dll. With GNU ld, I am trying to do this:

arm-wince-pe-ld hello.o -o hello.exe -M -e mainACRTStartup \
--image-base 0x00010000 -nostdlib --section-alignment 4096 \
--stack 0x10000 -L../../../lib -L/usr/local/wince/lib/gcc-lib/arm-wince-pe/3.2 \
-lcorelibc -lcoredll -lgcc

The link completes successfully, but the results do not run on WinCE 3.0.
The test program appears to "hang" before it actually gets into main().
Do you think that we're close to having something that works?

> How did you fix the WinCE-headers, so that they would be compatible
> with GCC ?  My tries with the MIPS and SH toolchains showed the MS-
> headers needing very much fixing for GCC...

I have done a fair amount of fixing of M$ WinCE 3.0 headers.  Usually
the things I've had to do are fairly straightforward, like replacing
__int64 with "long long".  But taken together, a fairly large number
of edits have been necessary.  This is still a work in progress, but
the M$ include files required for my test program are now working
correctly with GCC.  I'd be happy to provide the modified header files
to anyone wanting to work with GCC/arm-wince-pe

> As you can see, nobody else can do the same you did and then see
> what happens... Telling what you did with the gcc-3.2 sources, what
> possible patches and from where, you did install, could be a good
> start. Otherwise don't expect others being capable to help you here.

Hopefully this submission will go some distance toward rectifying this.
I'd like to know:  Has anyone else gotten GCC/arm-wince-pe to work
with WinCE 3.0?  Is arm-wince-pe really a supported configuration
for gcc-3.2 as it appears or am I just clueless?

> The ARM/EPOC has used probably quite the same 'arm-pe' format as
> ARM/WinCE, and if you ask Nokia, Motorola, Samsung, Siemens etc.,
> they probably claim that GCC works with EPOC when using the
> 'arm-epoc-pe' target, at least in the EPOC's own SDKs with GCC...
> (available free, Nokia snailmails the SDK6 CDROM if one cannot
> download it)

> BTW, the Intel/RedHat XScale-toolchain distribution (gcc-3.1) seems
> to have the 'arm-wince-pe' support straight from the box. What were
> the experiences with this?

Both of these are quite interesting to us.  Where could we get the
Intel/Redhat XScale toolchain distribution?  Is that something that
Intel provides?  I will check it out, and perhaps we can try it.  Kai,
thank you very much for the assistance.  I'm still hoping that we'll
find a way to get this working.

regards,
craig vanderborgh
voxware incorporated


------- End of forwarded message -------

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]