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: SH3 G++ Problems/sh-wince-pe


"Keuchel, Rainer" wrote:
> 
> >  Generally the gcc-3.0.x is quite unstable. While I got the
> > gcc-3.0.2 built for 'arm-elf', the 'gcc-3.0.3' crashed when trying to
> 
> I managed a build for arm-wince-pe with some patches. Exceptions work.

 When there are at least two common 'arm-pe' targets, the 'arm-epoc-pe'
and the 'arm-wince-pe', perhaps more than only a few people have looked at the
'arm-pe' targets than the 'mips-pe' and 'sh-pe' (and 'mcore-pe') targets. And
I have understood that the WinCE 3.0/PocketPC is now only for ARM, not for MIPS
and SH any more... So I'm not surprised if the ARM-port works better than the
SH and MIPS ports.

 I tried the 'arm-epoc-pe' with gcc-3.0.x and it seemed to produce a 'working'
GCC which didn't vomit when seeing the EPOC C++ headers, as the 2.9-branch did.
Somehow the 'gcc-2.7.2' from 1996 in the EPOC SDK 5 (haven't yet seen the SDK 6)
sounded as 'obsolete' to me... Knock, knock Nokia, Sony-Ericsson, Motorola,...
anybody home...

 When the 'Platform-SDK' headers cannot be used 'out of the box' with GCC in
Cygwin and Mingw, I assume you knowing some fixes for the WinCE-SDK headers
with GCC...

> > The 'sh-wince-pe' isn't supported even in the current
> > gcc-3.1' snapshots
> I see. That's why I try to make it work...
> I did not install any patches but made the changes myself.

 But I assume you having looked at the patches from the Cygnus/RedHat people,
published in the 'gcc-patches' maillist, in early 2000 ?  Or did you really
start from scratch again ?

 BTW, what is wrong with the gcc-2.9-branch and the WinCE 2.0 targets ?  I remember
the SH and MIPS headers and libs for WinCE 2.0 being from 1997, so at least the
C-parts aren't so 'up-to-date'...

> >  But the WinCE-target is very Windows-like with all kind of
> > '__stdcall' etc weirdnesses.
> 
> Yes, the calling convention is different for dlls, but I made it
> work with some assembler tricks in dlltool. It works with gcc
> and simple c++. Only problem still is returnvalues > 32 bits.
> This would mean that math functions from ms dlls cannot be used,
> but that should be no problem.

 The Cygnus/RedHat patches included all kind of things like adding
the 'dllexport' and 'dllimport' attributes for functions in the
'gcc/config/sh/sh.c'. Perhaps there could be something new for your
SH/PE-port case too... The SH support stuff in 2.9 and 3.0 isn't that
much different. Or stepping backwards to gcc-2.9-branch with the SH
and MIPS WinCE 2.0 cases (no WinCE 3.0 for them?) could perhaps make
the toolsets to work a little better.  I really don't know what is
so beautiful in the C++ support in gcc-3.x if the C-parts don't work...

 I can try to dig the WinCE-patches for gcc-2.9x from my archives and
email them if you cannot find them in the 'gcc-patches' archives and
want to see them...

> I suspect a problem with typeinfo. Problem is that I have to debug
> with a self-made debugger, but I think I will finally solve the issues
> with exceptions and stdlib... And get gdb and stub running...

 AFAIK the current GDB/Insight sources have support for WinCE and they
include something for running in the WinCE-target...

----------------- clip from gdb/wince.c ---------------------------------
/* Target-vector operations for controlling Windows CE child processes, for GDB.
   Copyright 1999, 2000, 2001 Free Software Foundation, Inc.
   Contributed by Cygnus Solutions, A Red Hat Company.
----------------- clip from gdb/wince.c ---------------------------------

 The GDB-host can only be Windoze, not Linux or something because the remote-
GDBs depend on some DLL coming with the "WinCE Services for Windows" or something,
the MS-package which provides the interface between a Windoze-PC and a WinCE-PDA.

 I assume you meaning these, not trying "to reinvent the wheel"... So GDB and the
Cygnus/RedHat-made stuff for remote debugging don't work well yet ?

 I really built Insights for all the three WinCE targets and the mystic DLL needed
at runtime was the hardest to find... But haven't had the opportunity to test them
or the gcc-2.9-based WinCE-toolchains ever...

 The 'i386-wince' libraries, ie. those for the 'WinCE'-emulator running in PC, seemed
to be made purely in C, so a 'i386-wince'-targeted GCC derived from the Mingw-port, or
putting the 'wince' being only one variation more in the current 'msvcrt' and 'crtdll'
choices in Mingw, could be possible...  Heard anyone working nowadays with this ?  The
EPOC-libs being written in C++ forces the developers (of this enemy of WinCE) to use
MS Visual C++ as the 'i386-epoc-pe' target compiler for the EPOC-emulator... Very
weird indeed to not produce the EPOC-emulator libs with Mingw when the ARM-target tools
are made using GCC... I would understand if the situation would be vice versa.

 Okeydokey, I would like to see someone wanting to experiment with the native Mingw and
it producing executables for the WinCE-emulator... The 'debugging' could be done somehow
this way too, and using VC++ for the emulator and GCC for the real targets doesn't sound
as 'compatible' than using GCC for both...

Cheers, Kai


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