Re: [Cegcc-devel] Build of cegcc fails

2006-10-30 Thread Pedro Alves
Not much time at the moment to analise this, quite swamped at work.

Nuno Lucas wrote:

> On 10/29/06, Kevin O'Connor <[EMAIL PROTECTED]> wrote:
>
>> Okay.  That seems to work.  The build still fails when it gets to gdb,
>> but that's not really a problem for me.  Haret seems to run fine with
>> the new compiler.
>
>
> I confirm this. An earlier revision before the C++ library was added
> was working fine (it was nice to see gdb working remotely), but now
> fails with "errno.h" errors when building gdb, and the strange thing
> is that it is including headers on /usr/include, which should never
> happen, I supose.
>

Not so strange because gdb is a host app, not a target app, so it builds 
with the native compiler libs and headers.
The problem is the hacky way wince's support is made. We pretend to be 
building
under ARM, through some magic (-D__arm__ -DARM -U_X86_ -U_M_IX86 
-U__i386__ -U__i486__ -U__i586__ -U__i686__).
This file need to include  and friends, so on linux, we are 
passing -I$(path to w32api/include) in CFLAGS.
On cygwin this was not a problem, since there w32api/include is already 
available in the standard package, and by somewhat of a
miracle everything built fine.

Since errno.h doesn't exist in mingw32ce, (or better we pretend it 
doesn't exist by using #include_next), the system (and correct) version
is being picked up but with the wrong machine defined (ARM instead of X86).
I've been waiting for when this ugly, ugly hack would break. :)
Limiting that hack to the files that need it (gdb/gdb/wince.c and 
friends) should do the trick. I hope.

As a workaround, maybe removing the #include_next logic in 
w32api/include would help.

The real solution would be to port gdbserver (there is a mingw port in 
gdb-cvs) to wince. The problem is that
gdbserver doesn't have dll debugging support. If that hack doesn't work, 
porting gdbserver should be a priority.
I've been meaning to do it for some time, and I guess now is the time...
Adding dll support is doable, but it requires hacking the gdb's remote 
protocol. Since desktop MinGW and cygwin would benefit from
this work too, we might get some good help from the gdb folks.

Cheers,
Pedro Alves


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel


Re: [Cegcc-devel] Build of cegcc fails

2006-10-30 Thread Pedro Alves
Pedro Alves wrote:

>Not much time at the moment to analise this, quite swamped at work.
>
>Nuno Lucas wrote:
>
>  
>
>>On 10/29/06, Kevin O'Connor <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>>Okay.  That seems to work.  The build still fails when it gets to gdb,
>>>but that's not really a problem for me.  Haret seems to run fine with
>>>the new compiler.
>>>  
>>>
>>I confirm this. An earlier revision before the C++ library was added
>>was working fine (it was nice to see gdb working remotely), but now
>>fails with "errno.h" errors when building gdb, and the strange thing
>>is that it is including headers on /usr/include, which should never
>>happen, I supose.
>>
>>
>>
>
>Not so strange because gdb is a host app, not a target app, so it builds 
>with the native compiler libs and headers.
>The problem is the hacky way wince's support is made. We pretend to be 
>building
>under ARM, through some magic (-D__arm__ -DARM -U_X86_ -U_M_IX86 
>-U__i386__ -U__i486__ -U__i586__ -U__i686__).
>This file need to include  and friends, so on linux, we are 
>passing -I$(path to w32api/include) in CFLAGS.
>On cygwin this was not a problem, since there w32api/include is already 
>available in the standard package, and by somewhat of a
>miracle everything built fine.
>
>Since errno.h doesn't exist in mingw32ce, (or better we pretend it 
>doesn't exist by using #include_next), the system (and correct) version
>is being picked up but with the wrong machine defined (ARM instead of X86).
>I've been waiting for when this ugly, ugly hack would break. :)
>Limiting that hack to the files that need it (gdb/gdb/wince.c and 
>friends) should do the trick. I hope.
>
>As a workaround, maybe removing the #include_next logic in 
>w32api/include would help.
>
>The real solution would be to port gdbserver (there is a mingw port in 
>gdb-cvs) to wince. The problem is that
>gdbserver doesn't have dll debugging support. If that hack doesn't work, 
>porting gdbserver should be a priority.
>I've been meaning to do it for some time, and I guess now is the time...
>Adding dll support is doable, but it requires hacking the gdb's remote 
>protocol. Since desktop MinGW and cygwin would benefit from
>this work too, we might get some good help from the gdb folks.
>
>  
>

Would just like to add that I suspect that the reason that 
arm-wince-mingw32ce-gdb is much slower on
linux that on cygwin is because we are picking up some wrong defines 
from the wrong headers.

>Cheers,
>Pedro Alves
>
>  
>


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel


Re: [Cegcc-devel] Build error with src/ scripts

2006-10-30 Thread Pedro Alves
Danny Backx wrote:
> Pedro,
>
> I just tried running your scripts in src/ to see whether they got me
> further than mine. Both fail in a similar way, can you help me out ?
>
>   
Strange, the host's gcc is calling the target's as?
> gcc -c   -O -I/usr/lesstif/include  -DIN_GCC -DCROSS_COMPILE  -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
>   
(...)
> /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc/gcc/cp/g++spec.c)
> /opt/cegcc/bin/arm-wince-cegcc-as: unrecognized option `-Qy'
>   
-Qy is an i386-as option. It definitely is calling the wrong as.

Are you building from src/?

Maybe there is an 'as' file on PATH that is calling arm-wince-cegcc-as?
What is your $PATH?
Humm, I have this wrapper $build-mingw32ce/gcc/gcc/as :
cat $build-mingw32ce/gcc/gcc/as
#!/bin/sh
exec /opt/mingw32ce/bin/arm-wince-mingw32ce-as "$@"

Maybe it is being called for some reason?

Maybe you could try adding a '-v' to CFLAGS, so we can understand why 
the wrong as is being called?

Cheers,
Pedro Alves


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel


Re: [Cegcc-devel] Build of cegcc fails

2006-10-30 Thread Danny Backx
If you're using the scripts/linux build, then yesterday's commits should
fix the build. If they don't, please tell me about it.

Danny

On Mon, 2006-10-30 at 00:26 +, Nuno Lucas wrote:
> On 10/29/06, Kevin O'Connor <[EMAIL PROTECTED]> wrote:
> > Okay.  That seems to work.  The build still fails when it gets to gdb,
> > but that's not really a problem for me.  Haret seems to run fine with
> > the new compiler.
> 
> I confirm this. An earlier revision before the C++ library was added
> was working fine (it was nice to see gdb working remotely), but now
> fails with "errno.h" errors when building gdb, and the strange thing
> is that it is including headers on /usr/include, which should never
> happen, I supose.
> 
> Regards,
> ~Nuno Lucas
> 
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ___
> Cegcc-devel mailing list
> Cegcc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


signature.asc
Description: This is a digitally signed message part
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel


Re: [Cegcc-devel] Build of cegcc fails

2006-10-30 Thread Danny Backx
On Mon, 2006-10-30 at 12:23 +, Pedro Alves wrote:
> >The real solution would be to port gdbserver (there is a mingw port in 
> >gdb-cvs) to wince. The problem is that
> >gdbserver doesn't have dll debugging support. If that hack doesn't work, 
> >porting gdbserver should be a priority.
> >I've been meaning to do it for some time, and I guess now is the time...
> >Adding dll support is doable, but it requires hacking the gdb's remote 
> >protocol. Since desktop MinGW and cygwin would benefit from
> >this work too, we might get some good help from the gdb folks.

> Would just like to add that I suspect that the reason that 
> arm-wince-mingw32ce-gdb is much slower on
> linux that on cygwin is because we are picking up some wrong defines 
> from the wrong headers.

Pedro,

Which defines, which headers ? If you have a reasonable clue then I
might want to dig in. Saves me time when debugging :-)

Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


signature.asc
Description: This is a digitally signed message part
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel


Re: [Cegcc-devel] Build of cegcc fails

2006-10-30 Thread Pedro Alves
Danny Backx wrote:

>On Mon, 2006-10-30 at 12:23 +, Pedro Alves wrote:
>  
>
>>>The real solution would be to port gdbserver (there is a mingw port in 
>>>gdb-cvs) to wince. The problem is that
>>>gdbserver doesn't have dll debugging support. If that hack doesn't work, 
>>>porting gdbserver should be a priority.
>>>I've been meaning to do it for some time, and I guess now is the time...
>>>Adding dll support is doable, but it requires hacking the gdb's remote 
>>>protocol. Since desktop MinGW and cygwin would benefit from
>>>this work too, we might get some good help from the gdb folks.
>>>  
>>>
>
>  
>
>>Would just like to add that I suspect that the reason that 
>>arm-wince-mingw32ce-gdb is much slower on
>>linux that on cygwin is because we are picking up some wrong defines 
>>from the wrong headers.
>>
>>
>
>Pedro,
>
>Which defines, which headers ? If you have a reasonable clue then I
>might want to dig in. Saves me time when debugging :-)
>  
>

I mean the w32api/include headers are picked up before the /usr/include 
headers. So if any
define happens to be different on the two something will break.
Things like the named values for errno (ENOSYS, ERANGE, etc.), the 
values to be passed to socket (SOCK_*),
to ioctl, the signals, etc, etc.

Cheer,
Pedro Alves


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel


Re: [Cegcc-devel] DLLs

2006-10-30 Thread Pedro Alves
Danny Backx wrote:
> Pedro,
>
> I approved a reply from you to the SVN-commits mailing list, but I
> didn't get the message through the mailing list yet. Maybe it has a
> backlog.
>
> If I remember the message well, it said that DLLs in mingw32ce need to
> be created by src/script.sh . This was in response to a change I made to
> get src/cegcc/libstdc++/Makefile to work for the arm-wince-mingw32ce
> target.
>
> Would you care to explain why this is so , or why you think it should be
> so ?
>   
Here is a (further enhanced) copy:

Dlls for mingw32ce runtime should be generated with src/script.sh .
That script was based on this other script:
http://cygwin.com/ml/cygwin-apps/2006-05/msg00044.html
That thread is really worth reading, as it talks about exactly
the same problems I am referring to.

There is on open issue of deciding if we want to go the dll route, 
or leave  everything static so we don't have any dll dependency.
The desktop version of MinGW goes the everything static route,
but there are some known problems with it when using recent versions of
gcc. There are problems in passing std::string around dlls,
and with exception propagation across dlls. 
They may switch to dll versions too when they switch to gcc-4.x (they still use 
gcc-3.x).
A possible cure for these problems is building libgcc and libstdc++ as dlls.
A possible cure for the std::string problem is building gcc/libstdc++ with 
'--enable-fully-dynamic-string', but that gives an inefficient std::string 
implementation,
as it disables the empty string optimization...

What do you guys think?
I don't have a problem in depending on a dll, but I am open to opinions.
If we decide on dlls, using 'arm-wince-mingw32ce -static' removes the 
dependencies,
so everybody should be happy.
We are talking about defaults here.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
Notice the posting /#17 by Danny Smith, a MinGW developer.

The src/script.sh does exactly that: build dlls from the static versions, and 
appends a 
version number to it so we can have multiple versions. Also, with these numbers 
attached,
there is no conflict with current cegcc's libsup++ and libstdc++ dlls, so they 
can be installed
side by side on the device.

Cheers,
Pedro Alves

/


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel


[Cegcc-devel] [commit] gcc WinCE support revamping.

2006-10-30 Thread Pedro Alves
Hi all,

I am commiting this patch that cleans up gcc's support of Windows CE for 
arm.

This patch fixes some major bugs/annoyances we had:

 - __declspec(dllexport/dllimport) was so broken that it was hurting.
We weren't passing -export= in .drectve properly,
so the linker would default to exporting everything. If you used .def 
files, this would go unnoticed.

 - We had some major violations of WinCE's ABI:

Currently this test gives wrong results:
struct abi_check_doubles { char a; double d; };
struct foo0 { char x; };
struct foo1 { char x;char :0; char y; };
struct foo2 { char x; int :0; int :0; int :0; int :0; char y; };
struct foo3 { char x; char :1; char y; };
struct foo4 { char x; int :1; char y; };

int main()
{
printf ("Size of foo0 is %d, should be 1\n", sizeof (struct foo0));
printf ("Size of foo1 is %d, should be 2\n", sizeof (struct foo1));
printf ("Size of foo2 is %d, should be 2\n", sizeof (struct foo2));
printf ("Size of foo3 is %d, should be 3\n", sizeof (struct foo3));
printf ("Size of foo4 is %d, should be 12\n", sizeof (struct foo4));
return 0;
}

The right results where taken from compiling the test case with MSVC.
Note that this is a simplified test case.
If you where experiencing weird crashes before while calling/interfacing 
MSVC/eVC compiled code,
including the system dlls, this may very well be the reason.

This patch also brings gcc support very close to what should be 
submitted upstream.

I'm only posting the ChangeLog, since the patch is pretty big. You can 
see it at cegcc-svn
or by svn updating.
I only tested this on mingw32ce yet, will test cegcc tomorrow.

Cheers,
Pedro Alves

---

src/gcc/gcc/ChangeLog.ce

2006-10-30  Pedro Alves  <[EMAIL PROTECTED]>

* target-def.h (TARGET_ATTRIBUTE_TABLE): Only define if not
defined before.
* config/arm/arm.c (arm_file_end): Give it external linkage.
(arm_handle_struct_attribute): New.
(arm_ms_bitfield_layout_p): New.
(TARGET_ATTRIBUTE_TABLE, TARGET_ASM_FILE_END,
TARGET_ENCODE_SECTION_INFO, TARGET_STRIP_NAME_ENCODING): Move
declarations to config/arm/arm.h.
(TARGET_MS_BITFIELD_LAYOUT_P): Define to
arm_ms_bitfield_layout_p.
(arm_return_in_memory): Replace #ifdef'ing on ARM_WINCE with
TARGET_RETURN_AGGREGATES_IN_MEMORY.
(arm_attribute_table): Add shared, ms_struct, gcc_struct
attributes.
Allow subtarget to add attributes using
SUBTARGET_ATTRIBUTE_TABLE.
(arm_elf_asm_constructor): Only compile on OBJECT_FORMAT_ELF.
(thumb_output_function_prologue): Call arm_pe_strip_name_encoding
instead of arm_strip_name_encoding.
(arm_handle_struct_attribute): New function.
(arm_ms_bitfield_layout_p): New function.
* config/arm/arm.h (TARGET_ASM_FILE_END, TARGET_ATTRIBUTE_TABLE,
TARGET_ENCODE_SECTION_INFO, TARGET_STRIP_NAME_ENCODING): Define.
* config/arm/t-wince-cegcc: Add cegcc1.o rule.
(TARGET_LIBGCC2_CFLAGS): Add -mwin32.
* config/arm/t-mingw32 (SYSTEM_INCLUDE_DIR): Delete.
(NATIVE_SYSTEM_HEADER_DIR): Likewise.
* config/arm/arm-protos.h (arm_file_end,
arm_pe_asm_named_section, arm_pe_section_type_flags,
arm_pe_strip_name_encoding, arm_pe_output_labelref,
arm_pe_handle_shared_attribute): Declare.
* config/arm/wince-pe.h:
(TARGET_VERSION): Set to "(arm Windows CE/Native SDK)".
(MULTILIB_DEFAULTS): Remove -mfpu=vfp.
(SUBTARGET_CPU_DEFAULT): Default to TARGET_CPU_arm8 (armv4).
(CPP_SPEC): Remove cegcc specifics.
(ASM_SPEC): Don't pass -cpu=iwmmxt to assembler when -mcpu=xscale
is used.
(SUBTARGET_EXTRA_SPECS, SUBTARGET_ASM_FLOAT_SPEC): Remove.
(TARGET_OS_CPP_BUILTINS): Add _stdcall, _fastcall and _cdecl.
(SUBTARGET_CPP_SPEC, HANDLE_SYSV_PRAGMA,
HANDLE_PRAGMA_PACK_PUSH_POP): Delete.
(STARTFILE_SPEC): Remove cegcc specifics.
(LIBGCC_SPEC): Likewise.
(LIB_SPEC): Likewise.
(COMMON_ASM_OP, ASM_OUTPUT_COMMON, ASM_DECLARE_OBJECT_NAME,
ASM_DECLARE_FUNCTION_NAME, ASM_OUTPUT_EXTERNAL,
ASM_OUTPUT_EXTERNAL_LIBCALL, ASM_OUTPUT_ALIGNED_BSS,
TARGET_ASM_FILE_END, SUPPORTS_ONE_ONLY, MULTIPLE_SYMBOL_SPACES):
Delete.
(ARM_MCOUNT_NAME): Define to _mcount to avoid conflicts.
(CHECK_STACK_LIMIT): Delete.
(TARGET_DEFAULT): Match Windows CE ABI with
MASK_MS_BITFIELD_LAYOUT and MASK_RETURN_AGGREGATES_IN_MEMORY.
(TARGET_SUBTARGET_DEFAULT): Delete.
(BIGGEST_FIELD_ALIGNMENT): Delete.
(SET_ASM_OP): Delete.
(DEFAULT_STRUCTURE_SIZE_BOUNDARY): Define to 8 as WinCE's ABI
requires.
(ASM_OUTPUT_DEF_FROM_DECLS, TARGET_USE_JCR_SECTION,
TARGET_USE_LOCAL_THUNK_ALIAS_P, SUBTARGET_ATTRIBUTE_TABLE):
Delete.
* config/arm/mingw32.h (STANDARD_INCLUDE_DIR,
STANDARD_INCLUDE_COMPONENT): Delete.
* config/arm/arm.opt: New option -mreturn-aggregates-in-memory.
* config/arm/pe.opt: New option -mms-bitfields.
* config/arm/pe.c (arm_pe_handle_shared_attribute): New.
(arm_pe_strip_name_encoding): New.
(arm_pe_o