cegcc-devel — Discussion about CeGCC development

Re: [Cegcc-devel] issues with MonitorFromPoint when compiling OpenGL ES 1.0 code

[Daniel M. <mon...@gm...>]

Tried that with a SDL app of mine (http://angstron2.garage.maemo.org , the
one Im trying to port to OpenGL ES), but the results were marginally better
(tunning for xscale). Its kind of weird, since I tried it on my
PXA270@315Mhz phone, running one of those chinese linuxes from Motorola and
it performs significantly better (tunned for iwxmmt).Same goes to Nokia N770
(Omap1710@200Mhz and bigger resolution, tunned for arm926ej-s).

This leads me to belive the graphical subsystem is fundamently crippled with
slow ARM4 code.

Daniel Monteiro
========================================
|_|0|_|  Linux Registered User #424188
|_|_|0| http://batterypoweredgames.blogspot.com/
|0|0|0| Visit to grab games for your mobile device!
========================================


2010/2/10 Vincent Richomme <fo...@sm...>

> On Tue, 9 Feb 2010 16:43:21 -0200, Daniel Monteiro
> <mon...@gm...> wrote:
> > Tried setting those by hand, but it generated link errors.
> > The said simbols actually looks like what I was looking for. Gonna try
> > those when I get home.
> > Also worth asking: Is it me or everything in WinMo is ARMv4, right?
>
> I would say WinMo environment is ARMv4i (thumb mode).
> For instance if we take native toolchain(Visual Studio) for Windows Mobile
> you have ARMv4 for Pocket PC 2003
> and then ARMv4i(thumb) for Windows Mobile. But you also have an option to
> compile in ARMv5 or ARMv5T.
> Since OEM are using a custom Visual Studio (called Platform Builder) I
> could say that in the best case they compile
> in ARMv5(T) but I would be surprised if they changed default settings.
> So my final answer is yes Windows Mobile environnment is compiled in
> ARMv4i but nothing prevents you to compile
> your application(userland) with a better version if you target cpu
> supports it.
>
>
>

Re: [Cegcc-devel] issues with MonitorFromPoint when compiling OpenGL ES 1.0 code

[Vincent R. <fo...@sm...>]

On Tue, 9 Feb 2010 16:43:21 -0200, Daniel Monteiro
<mon...@gm...> wrote:
> Tried setting those by hand, but it generated link errors.
> The said simbols actually looks like what I was looking for. Gonna try
> those when I get home.
> Also worth asking: Is it me or everything in WinMo is ARMv4, right?

I would say WinMo environment is ARMv4i (thumb mode).
For instance if we take native toolchain(Visual Studio) for Windows Mobile
you have ARMv4 for Pocket PC 2003
and then ARMv4i(thumb) for Windows Mobile. But you also have an option to
compile in ARMv5 or ARMv5T.
Since OEM are using a custom Visual Studio (called Platform Builder) I
could say that in the best case they compile
in ARMv5(T) but I would be surprised if they changed default settings.
So my final answer is yes Windows Mobile environnment is compiled in
ARMv4i but nothing prevents you to compile
your application(userland) with a better version if you target cpu
supports it.

Re: [Cegcc-devel] issues with MonitorFromPoint when compiling OpenGL ES 1.0 code

[Danny B. <dan...@sc...>]

On Tue, 2010-02-09 at 16:43 -0200, Daniel Monteiro wrote:
> Tried setting those by hand, but it generated link errors.

Please specify what the problem is. coredll does contain the symbols
that I just added to winuser.h .

> The said simbols actually looks like what I was looking for. Gonna try
> those when I get home.
> Also worth asking: Is it me or everything in WinMo is ARMv4, right?

What exactly is your question ?

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

Re: [Cegcc-devel] issues with MonitorFromPoint when compiling OpenGL ES 1.0 code

[Daniel M. <mon...@gm...>]

Tried setting those by hand, but it generated link errors.
The said simbols actually looks like what I was looking for. Gonna try
those when I get home.
Also worth asking: Is it me or everything in WinMo is ARMv4, right?

cheers
Daniel Monteiro
========================================
|_|0|_|  Linux Registered User #424188
|_|_|0| http://batterypoweredgames.blogspot.com/
|0|0|0| Visit to grab games for your mobile device!
========================================


2010/2/9 Danny Backx <dan...@sc...>

> On Tue, 2010-02-09 at 09:15 -0200, Daniel Monteiro wrote:
> > Hello there. I've been trying to compile the example codes from the
> > Windows Mobile 2003 SE SDK from Imagination Technologies for OpenGL ES
> > 1.0 Common Lite profile. My current commandline is:
> > arm-wince-mingw32ce-g++  -DARMV4 -D_ARM_ -DUNICODE -D_UNICODE
> > -DPVRT_FIXED_POINT_ENABLE -DDEBUG -D_WIN32_IE=0x0400
> > -I/home/daniel/Desktop/testegl/Include
> > -I/home/daniel/Desktop/testegl/Windows/Include
> > -L/home/daniel/Desktop/testegl/PocketPCARMV4/Lib
> > OGLESHelloTriangle_Windows.cpp -oteste.exe -llibGLES_CL
> >
> > There are probably better ways to do it, but I want to make something
> > easy to drop in and start compiling. Everything ALMOST works. I get
> > the following messages from the compiler:
> > OGLESHelloTriangle_Windows.cpp: In function 'int WinMain(HINSTANCE__*,
> > HINSTANCE__*, TCHAR*, int)':
> > OGLESHelloTriangle_Windows.cpp:163: error: 'MONITOR_DEFAULTTOPRIMARY'
> > was not declared in this scope
>
> Hmm, I'm not sure what you mean by "almost works" if it doesn't get
> compiled yet :-)
>
> Getting values for such symbols is often not so easy, we don't want to
> start reading copyrighted Microsoft documents, that would affect the
> cegcc license in a bad way.
>
> However :
> http://doxygen.reactos.org/da/d64/winuser_8h_source.html says the value
> for this macro should be 1.
>
> Also http://www.codeproject.com/KB/dialog/EnsureRectangleOnDisplay.aspx
> confirms this.
>
> > OGLESHelloTriangle_Windows.cpp:163: error: 'MonitorFromPoint' was not
> > declared in this scope
>
> This appears to be in our winuser.h but hidden behind the wrong
> symbols :
> #if (_WIN32_WINNT >= 0x0500 || _WIN32_WINDOWS >= 0x0410)
> WINUSERAPI HMONITOR WINAPI MonitorFromPoint(POINT,DWORD);
>
> Could you check whether use of the value 1 for the macro above helps you
> out ?
>
>        Danny
>
> --
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
>
>

Re: [Cegcc-devel] ICE error: unrecognizable insn

[Pavel P. <pa...@su...>]

> > I just took latest svn cegcc and wanted to test if the loading error
> > was fixed (the infamous problem that is only fixed by using upx).
> 
> Partially. It may work for you, give it a try.
> 

Surprisingly, I got opposite behavior with the dll binaries compiled with latest cegcc: they load fine without upx compression and do not load at all if upx-compressed. Anyways, binaries compiled with the latest cegcc do not work when I use them (app crashes). When dlls are upx compressed at the time of loading of my app I'm seeing unaligned access error in vs debugger.


> > But I can’t even compile my code, I’m getting ICE.
> 
> 
> > PS. What about that error, that binaries built with cegcc do not load
> > on most modern devices? Is it fixed now?
> 
> Isn't that the same problem as you asked about at the beginning ?


Yes, I wanted to see if the loading issue was fixed in latest binutils, but I wasn't able to compile my dll using latest cegcc. The email primarily related to the ICE error.


> 
> > Preprocessed imgconvert.c  is attached in a zip
> 
> I had to edit one line to remove a syntax error, from
> void (*butterflies_float)(float *restrict v1, float *restrict v2, int
> len);
> to
> void (*butterflies_float)(float *v1, float *v2, int len);
> 
> After that, I got a similar error as you did.
> 
> Does anyone have a quick way of testing whether this happens also with
> a
> native gcc 4.4.0 ?


I doubt that, this is latest svn code from ffmpeg and most likely native builds are done by many people using gcc440. I googled a similar error reported for cegcc a while ago and somebody mentioned that they forgot to apply some patch related to dllimport/dllexport. It could be related: if I remove dllimport attribute then I don't get any errors at all.



Other than that, I'm getting tons of warnings related to inline asm. Something like: Source R0 and R1 have to be different.

Re: [Cegcc-devel] issues with MonitorFromPoint when compiling OpenGL ES 1.0 code

[Danny B. <dan...@sc...>]

On Tue, 2010-02-09 at 09:15 -0200, Daniel Monteiro wrote:
> Hello there. I've been trying to compile the example codes from the
> Windows Mobile 2003 SE SDK from Imagination Technologies for OpenGL ES
> 1.0 Common Lite profile. My current commandline is:
> arm-wince-mingw32ce-g++  -DARMV4 -D_ARM_ -DUNICODE -D_UNICODE
> -DPVRT_FIXED_POINT_ENABLE -DDEBUG -D_WIN32_IE=0x0400
> -I/home/daniel/Desktop/testegl/Include
> -I/home/daniel/Desktop/testegl/Windows/Include
> -L/home/daniel/Desktop/testegl/PocketPCARMV4/Lib
> OGLESHelloTriangle_Windows.cpp -oteste.exe -llibGLES_CL
> 
> There are probably better ways to do it, but I want to make something
> easy to drop in and start compiling. Everything ALMOST works. I get
> the following messages from the compiler:
> OGLESHelloTriangle_Windows.cpp: In function 'int WinMain(HINSTANCE__*,
> HINSTANCE__*, TCHAR*, int)':
> OGLESHelloTriangle_Windows.cpp:163: error: 'MONITOR_DEFAULTTOPRIMARY'
> was not declared in this scope

Hmm, I'm not sure what you mean by "almost works" if it doesn't get
compiled yet :-)

Getting values for such symbols is often not so easy, we don't want to
start reading copyrighted Microsoft documents, that would affect the
cegcc license in a bad way.

However :
http://doxygen.reactos.org/da/d64/winuser_8h_source.html says the value
for this macro should be 1.

Also http://www.codeproject.com/KB/dialog/EnsureRectangleOnDisplay.aspx
confirms this.

> OGLESHelloTriangle_Windows.cpp:163: error: 'MonitorFromPoint' was not
> declared in this scope

This appears to be in our winuser.h but hidden behind the wrong
symbols : 
#if (_WIN32_WINNT >= 0x0500 || _WIN32_WINDOWS >= 0x0410)
WINUSERAPI HMONITOR WINAPI MonitorFromPoint(POINT,DWORD);

Could you check whether use of the value 1 for the macro above helps you
out ?

	Danny

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

Re: [Cegcc-devel] ICE error: unrecognizable insn

[Danny B. <dan...@sc...>]

On Mon, 2010-02-08 at 21:24 -0500, Pavel Pavlov wrote:
> I just took latest svn cegcc and wanted to test if the loading error
> was fixed (the infamous problem that is only fixed by using upx).

Partially. It may work for you, give it a try.

> But I can’t even compile my code, I’m getting ICE.


> PS. What about that error, that binaries built with cegcc do not load
> on most modern devices? Is it fixed now?

Isn't that the same problem as you asked about at the beginning ?

> Preprocessed imgconvert.c  is attached in a zip

I had to edit one line to remove a syntax error, from
void (*butterflies_float)(float *restrict v1, float *restrict v2, int
len);
to
void (*butterflies_float)(float *v1, float *v2, int len);

After that, I got a similar error as you did.

Does anyone have a quick way of testing whether this happens also with a
native gcc 4.4.0 ?

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

[Cegcc-devel] issues with MonitorFromPoint when compiling OpenGL ES 1.0 code

[Daniel M. <mon...@gm...>]

Hello there. I've been trying to compile the example codes from the Windows
Mobile 2003 SE SDK from Imagination Technologies for OpenGL ES 1.0 Common
Lite profile. My current commandline is:
arm-wince-mingw32ce-g++  -DARMV4 -D_ARM_ -DUNICODE -D_UNICODE
-DPVRT_FIXED_POINT_ENABLE -DDEBUG -D_WIN32_IE=0x0400
-I/home/daniel/Desktop/testegl/Include
-I/home/daniel/Desktop/testegl/Windows/Include
-L/home/daniel/Desktop/testegl/PocketPCARMV4/Lib
OGLESHelloTriangle_Windows.cpp -oteste.exe -llibGLES_CL

There are probably better ways to do it, but I want to make something easy
to drop in and start compiling. Everything ALMOST works. I get the following
messages from the compiler:
OGLESHelloTriangle_Windows.cpp: In function 'int WinMain(HINSTANCE__*,
HINSTANCE__*, TCHAR*, int)':
OGLESHelloTriangle_Windows.cpp:163: error: 'MONITOR_DEFAULTTOPRIMARY' was
not declared in this scope
OGLESHelloTriangle_Windows.cpp:163: error: 'MonitorFromPoint' was not
declared in this scope
OGLESHelloTriangle_Windows.cpp:388: warning: passing NULL to non-pointer
argument 3 of 'BOOL PeekMessageW(tagMSG*, HWND__*, UINT, UINT, UINT)'
OGLESHelloTriangle_Windows.cpp:388: warning: passing NULL to non-pointer
argument 4 of 'BOOL PeekMessageW(tagMSG*, HWND__*, UINT, UINT, UINT)'

Im using the binary distribution 0.59 and Im using Ubuntu 9.04. The line
causing the errors is the following:

163: hMonitor    = MonitorFromPoint(p, MONITOR_DEFAULTTOPRIMARY);

(I belive I shouldnt worry about the warnings, right?)

Im wondering. Its probably a missing include or perhaps a missing library
(or both?). What should I do? And congrats for the amazing project.

cheers

Daniel "NeoStrider" Monteiro
========================================
|_|0|_|  Linux Registered User #424188
|_|_|0| http://batterypoweredgames.blogspot.com/
|0|0|0| Visit to grab games for your mobile device!
========================================

Re: [Cegcc-devel] TransparentBlt()

[Vincent R. <fo...@sm...>]

On Sat, 06 Feb 2010 10:17:44 +0100, Vincent Richomme
<fo...@sm...> wrote:
> On Sat, 06 Feb 2010 08:29:41 +0100, Danny Backx <dan...@sc...>
> wrote:
>> On Sat, 2010-02-06 at 00:45 +0100, Max Kellermann wrote:
>>> On 2010/01/29 18:06, Danny Backx <dan...@sc...> wrote:
>>> > On Tue, 2010-01-26 at 23:14 +0100, Max Kellermann wrote:
>>> > > When I attempt to force WINVER=0x410, the linker bails out with
>>> > > "undefined reference to `TransparentBlt'".
>>> > 
>>> > Does the change that I just committed work for you ?
>>> 
>>> (Sorry for the late response)
>>> 
>>> That fixes the declaration problem, but the "undefined reference"
>>> linker error persists.
>> 
>> The patch below can add this to coredll6.a
>> I am suggesting this because I don't know which version to put this in.

>> 
>> 	Danny
>> 
>> pavilion: {299} cd src/mingw
>> pavilion: {300} svn diff coredll6.def
>> Index: coredll6.def
>> ===================================================================
>> --- coredll6.def        (revision 1435)
>> +++ coredll6.def        (working copy)
>> @@ -1664,6 +1664,10 @@
>>  wvsprintfW
>>  
>>  ;
>> +; Not sure from which version
>> +;
>> +TransparentBlt
>> +;
>>  ; Stuff for Windows CE / Windows Mobile 6.x
>>  ;
>>  CeSetThreadPriority
>> pavilion: {301}
> 
> WM 6.0 is not officially released so I don't think so you modified the
> right file ...
> http://msdn.microsoft.com/en-us/library/aa929119.aspx
> 
> You should report it in coredell.def
> 

Forget my least email I just woke up 10 minutes ago.
So your change should be good.

Re: [Cegcc-devel] TransparentBlt()

[Vincent R. <fo...@sm...>]

On Sat, 06 Feb 2010 08:29:41 +0100, Danny Backx <dan...@sc...>
wrote:
> On Sat, 2010-02-06 at 00:45 +0100, Max Kellermann wrote:
>> On 2010/01/29 18:06, Danny Backx <dan...@sc...> wrote:
>> > On Tue, 2010-01-26 at 23:14 +0100, Max Kellermann wrote:
>> > > When I attempt to force WINVER=0x410, the linker bails out with
>> > > "undefined reference to `TransparentBlt'".
>> > 
>> > Does the change that I just committed work for you ?
>> 
>> (Sorry for the late response)
>> 
>> That fixes the declaration problem, but the "undefined reference"
>> linker error persists.
> 
> The patch below can add this to coredll6.a
> I am suggesting this because I don't know which version to put this in. 
> 
> 	Danny
> 
> pavilion: {299} cd src/mingw
> pavilion: {300} svn diff coredll6.def
> Index: coredll6.def
> ===================================================================
> --- coredll6.def        (revision 1435)
> +++ coredll6.def        (working copy)
> @@ -1664,6 +1664,10 @@
>  wvsprintfW
>  
>  ;
> +; Not sure from which version
> +;
> +TransparentBlt
> +;
>  ; Stuff for Windows CE / Windows Mobile 6.x
>  ;
>  CeSetThreadPriority
> pavilion: {301}

WM 6.0 is not officially released so I don't think so you modified the
right file ...
http://msdn.microsoft.com/en-us/library/aa929119.aspx

You should report it in coredell.def

Re: [Cegcc-devel] TransparentBlt()

[Danny B. <dan...@sc...>]

On Sat, 2010-02-06 at 00:45 +0100, Max Kellermann wrote:
> On 2010/01/29 18:06, Danny Backx <dan...@sc...> wrote:
> > On Tue, 2010-01-26 at 23:14 +0100, Max Kellermann wrote:
> > > When I attempt to force WINVER=0x410, the linker bails out with
> > > "undefined reference to `TransparentBlt'".
> > 
> > Does the change that I just committed work for you ?
> 
> (Sorry for the late response)
> 
> That fixes the declaration problem, but the "undefined reference"
> linker error persists.

The patch below can add this to coredll6.a
I am suggesting this because I don't know which version to put this in. 

	Danny

pavilion: {299} cd src/mingw
pavilion: {300} svn diff coredll6.def
Index: coredll6.def
===================================================================
--- coredll6.def        (revision 1435)
+++ coredll6.def        (working copy)
@@ -1664,6 +1664,10 @@
 wvsprintfW
 
 ;
+; Not sure from which version
+;
+TransparentBlt
+;
 ; Stuff for Windows CE / Windows Mobile 6.x
 ;
 CeSetThreadPriority
pavilion: {301} 

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

Re: [Cegcc-devel] TransparentBlt()

[Max K. <ma...@du...>]

On 2010/01/29 18:06, Danny Backx <dan...@sc...> wrote:
> On Tue, 2010-01-26 at 23:14 +0100, Max Kellermann wrote:
> > When I attempt to force WINVER=0x410, the linker bails out with
> > "undefined reference to `TransparentBlt'".
> 
> Does the change that I just committed work for you ?

(Sorry for the late response)

That fixes the declaration problem, but the "undefined reference"
linker error persists.

Max

Re: [Cegcc-devel] limits.h not found

[Vincent T. <vt...@un...>]

Hey,

So, is there some fixes that has been pushed in svn ?

Vincent Torri

Re: [Cegcc-devel] Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

[Sébastien L. <sq...@gm...>]

Notice I pasted twice the last loop. It only happens once.

Re: [Cegcc-devel] Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

[Sébastien L. <sq...@gm...>]

First step: run arm-mingw32ce-gcc -g --save-temps test.c -o test.exe
this crashes after quite a LONG time (several seconds).

then:

C:\MinGW>del test.o

C:\MinGW>gcc3\bin\gdb.exe arm-mingw32ce-as.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) break coffcode.h:3656
Breakpoint 1 at 0x45fef1: file
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h, line 3656. (2
locations)
(gdb) run test.s
Starting program: c:\MinGW\cross41-debug\bin/arm-mingw32ce-as.exe test.s
[New thread 2316.0x3b0]

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h: No such
file or directory.
        in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
(gdb) print len
$1 = 5
(gdb) print string_size
$2 = 4
(gdb) print *current
$3 = {name = 0x4a0a6e ".text", id = 16, index = 0, next = 0x1591608, prev =
0x0, flags = 279, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0,
use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma =
0, size = 72, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591550, alignment_power = 2,
relocation = 0x0, orelocation = 0x14e54a0, reloc_count = 2, filepos = 500,
  rel_filepos = 1596, line_filepos = 0, userdata = 0x2328b0, contents = 0x0,
lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 1, used_by_bfd = 0x0,
constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3358,
  symbol_ptr_ptr = 0x15915e8, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
(gdb)

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
(gdb) display len
1: len = 5
(gdb) display string_size
2: string_size = 4
(gdb) display *current
3: *current = {name = 0x4a0a74 ".data", id = 17, index = 1, next =
0x15916c0, prev = 0x1591550, flags = 3, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0,
use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma =
0, size = 0, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591608, alignment_power = 2,
relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 0,
  rel_filepos = 0, line_filepos = 0, userdata = 0x2328f8, contents = 0x0,
lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 2, used_by_bfd = 0x0,
constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e34c0,
  symbol_ptr_ptr = 0x15916a0, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
(gdb)
(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x4a0a7a ".bss", id = 18, index = 2, next = 0x15918e8,
prev = 0x1591608, flags = 1, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0,
use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma =
0, size = 0, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x15916c0, alignment_power = 2,
relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 0,
  rel_filepos = 0, line_filepos = 0, userdata = 0x232940, contents = 0x0,
lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 3, used_by_bfd = 0x0,
constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3628,
  symbol_ptr_ptr = 0x1591758, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 4
1: len = 4

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7418 ".debug_abbrev", id = 21, index = 3, next =
0x15919a0, prev = 0x15916c0, flags = 298, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0,
sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0,
reloc_done = 0, vma = 0, lma = 0, size = 145, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x15918e8,
alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0,
  filepos = 572, rel_filepos = 0, line_filepos = 0, userdata = 0x16d7440,
contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 4, used_by_bfd
= 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3d58,
  symbol_ptr_ptr = 0x1591980, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 4
1: len = 13

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14e6518 ".debug_info", id = 22, index = 4, next =
0x1591a58, prev = 0x15918e8, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0,
sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0,
reloc_done = 0, vma = 0, lma = 0, size = 451, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x15919a0,
alignment_power = 0, relocation = 0x0, orelocation = 0x1814718, reloc_count
= 9,
  filepos = 717, rel_filepos = 1616, line_filepos = 0, userdata = 0x14e6540,
contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 5, used_by_bfd
= 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3ee8,
  symbol_ptr_ptr = 0x1591a38, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 18
1: len = 11

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14e75e0 ".debug_line", id = 23, index = 5, next =
0x1591b10, prev = 0x15919a0, flags = 8460, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0,
sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0,
reloc_done = 0, vma = 0, lma = 0, size = 248, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591a58,
alignment_power = 0, relocation = 0x0, orelocation = 0x18149e0, reloc_count
= 1,
  filepos = 1168, rel_filepos = 1706, line_filepos = 0, userdata =
0x14e8600, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 6, used_by_bfd
= 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e4078,
  symbol_ptr_ptr = 0x1591af0, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 30
1: len = 11

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14e96f8 ".rdata", id = 24, index = 6, next =
0x1591bc8, prev = 0x1591a58, flags = 290, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0,
use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma =
0, size = 12, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591b10, alignment_power = 2,
relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 1416,
  rel_filepos = 0, line_filepos = 0, userdata = 0x14e9718, contents = 0x0,
lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 7, used_by_bfd = 0x0,
constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e77a0,
  symbol_ptr_ptr = 0x1591ba8, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 42
1: len = 6

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14ecf58 ".debug_frame", id = 25, index = 7, next =
0x1591c80, prev = 0x1591b10, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0,
sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0,
reloc_done = 0, vma = 0, lma = 0, size = 48, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591bc8,
alignment_power = 2, relocation = 0x0, orelocation = 0x1814a68, reloc_count
= 2,
  filepos = 1428, rel_filepos = 1716, line_filepos = 0, userdata =
0x14ecf80, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 8, used_by_bfd
= 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e7b88,
  symbol_ptr_ptr = 0x1591c60, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 42
1: len = 12

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14edfc8 ".debug_loc", id = 26, index = 8, next =
0x1591d38, prev = 0x1591bc8, flags = 298, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0,
sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0,
reloc_done = 0, vma = 0, lma = 0, size = 42, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591c80,
alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0,
  filepos = 1476, rel_filepos = 0, line_filepos = 0, userdata = 0x16d7868,
contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 9, used_by_bfd
= 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e7e08,
  symbol_ptr_ptr = 0x1591d18, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 55
1: len = 10

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d79b0 ".debug_pubnames", id = 27, index = 9, next
= 0x1591df0, prev = 0x1591c80, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0,
sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0,
reloc_done = 0, vma = 0, lma = 0, size = 30, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591d38,
alignment_power = 0, relocation = 0x0, orelocation = 0x1814b38, reloc_count
= 1,
  filepos = 1518, rel_filepos = 1736, line_filepos = 0, userdata =
0x16d79d8, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 10,
used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol =
0x14e7fc0,
  symbol_ptr_ptr = 0x1591dd0, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 66
1: len = 15

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7a20 ".debug_aranges", id = 28, index = 10, next
= 0x1591ea8, prev = 0x1591d38, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0,
sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0,
reloc_done = 0, vma = 0, lma = 0, size = 32, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591df0,
alignment_power = 0, relocation = 0x0, orelocation = 0x1814ba0, reloc_count
= 2,
  filepos = 1548, rel_filepos = 1746, line_filepos = 0, userdata =
0x16d7a48, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 11,
used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol =
0x14e8128,
  symbol_ptr_ptr = 0x1591e88, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 82
1: len = 14

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7a90 ".debug_str", id = 29, index = 11, next =
0x0, prev = 0x1591df0, flags = 298, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0,
use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma =
0, size = 13, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591ea8, alignment_power = 0,
relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 1580,
  rel_filepos = 0, line_filepos = 0, userdata = 0x16d7ab8, contents = 0x0,
lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 12, used_by_bfd = 0x0,
constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e8290,
  symbol_ptr_ptr = 0x1591f40, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 97
1: len = 10

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at
/home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7a90 ".debug_str", id = 29, index = 11, next =
0x0, prev = 0x1591df0, flags = 298, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0,
use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma =
0, size = 13, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591ea8, alignment_power = 0,
relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 1580,
  rel_filepos = 0, line_filepos = 0, userdata = 0x16d7ab8, contents = 0x0,
lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 12, used_by_bfd = 0x0,
constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e8290,
  symbol_ptr_ptr = 0x1591f40, map_head = {link_order = 0x0, s = 0x0},
map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 97
1: len = 10
(gdb) c
Continuing.

Program exited normally.


All of this seems very normal to me. What about you?

Sebastien

Re: [Cegcc-devel] Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

[Dave K. <dav...@go...>]

On 31/01/2010 22:32, Sébastien Lorquet wrote:

> as is generating garbage and ld and objdump are victims.

  Yep.  The section headers are full of nonsense.  The string table is present
and all the long section names are there, but all the section headers containt
"/1579551", which is way out of range.

  We need to debug what's going on in coff_write_object_contents() in the
assembler.  If you walk through this loop:

  for (current = abfd->sections;
       current != NULL;
       current = current->next)
    {
      struct internal_scnhdr section;
      bfd_boolean is_reloc_section = FALSE;


... checking the contents of 'current' each time, and then seeing what happens
to len and string_size here:

      /* Handle long section names as in PE.  This must be compatible
	 with the code in coff_write_symbols and _bfd_coff_final_link.  */
      if (bfd_coff_long_section_names (abfd))
	{
	  size_t len;

	  len = strlen (current->name);
	  if (len > SCNNMLEN)
	    {
              [ ... more ... ]
	      string_size += len + 1;
	      long_section_names = TRUE;
	    }
	}

... we should get some idea what's going wrong.

    cheers,
      DaveK

Re: [Cegcc-devel] investigations about arm-mingw32ce-ar.exe failure on i586-mingw32msvc host

[Sébastien L. <sq...@gm...>]

sorry false alarm. This does NOT fix anything.

another sample output from my decoder:

reading global header for
C:\sources\ucvm\trunk\Debug\arm-wince\libloaderfs.a
global header: !<arch>

global header ok
file name: /
this is the symbol lookup table
file mod timestamp: 666709491344
file oid: 197232
file gid: 666709
file mode: 10604430
file size: 142
magic 1 ok
magic 2 ok
skipping file contents (142 bytes)
file name: //
this is the extended file list
file mod timestamp:
file oid:
file gid:
file mode:
file size: 3006477109
magic 1 ok
magic 2 ok
invalid size, cannot continue: For input string: "3006477109"

The file mod is not even a valid octal string.

Re: [Cegcc-devel] limits.h not found

[Dave K. <dav...@go...>]

On 31/01/2010 15:39, Dave Korn wrote:

>   I'll try a full clean build with nothing preinstalled and this patch:
> 
> Index: build-mingw32ce.sh
> ===================================================================
> --- build-mingw32ce.sh  (revision 1440)
> +++ build-mingw32ce.sh  (working copy)
> @@ -341,6 +341,7 @@ build_gcc()
>              --disable-interwork            \
>              --without-newlib               \
>              --enable-checking              \
> +            --with-headers=${PREFIX}/${TARGET}/include \
>              --with-headers                     \
>              --disable-__cxa_atexit
>          ;;

  That was wrong, because I forgot to remove the empty --with-headers option
on the next line.  JFTR, because Pedro's patch is probably the better
approach, this worked:

Index: build-mingw32ce.sh
===================================================================
--- build-mingw32ce.sh  (revision 1440)
+++ build-mingw32ce.sh  (working copy)
@@ -322,7 +322,7 @@ build_gcc()
             --disable-interwork            \
             --without-newlib               \
             --enable-checking              \
-            --with-headers
+            --with-headers=${PREFIX}/${TARGET}/include
         ;;
         gcc-*)
            ${BASE_DIRECTORY}/${gcc_src}/configure      \
@@ -341,7 +341,7 @@ build_gcc()
             --disable-interwork            \
             --without-newlib               \
             --enable-checking              \
-            --with-headers                     \
+            --with-headers=${PREFIX}/${TARGET}/include \
             --disable-__cxa_atexit
         ;;
     esac

    cheers,
      DaveK

Re: [Cegcc-devel] limits.h not found

[Pedro A. <pe...@co...>]

[ I'm going AFK from a couple of hours, so let me reply quickly
just half the questions ]

On Sunday 31 January 2010 17:06:32, Dave Korn wrote:

>   LOL, that made me do a double-take.  Err?  Is this maybe deliberate because
> (WAG) fastcall doesn't mean anything on CE or some such reason?

Yes, exactly that.  :-)

config/arm/wince-pe.h:

          /* Let's just ignore stdcall, and fastcall.  */               \
      builtin_define ("__stdcall=__attribute__((__cdecl__))");          \
      builtin_define ("__fastcall=__attribute__((__cdecl__))");         \
      builtin_define ("__cdecl=__attribute__((__cdecl__))");            \

ISTR that's what MSVC does too (or defines empty), but I may be wrong.

CE's function call ABI is all cdecl.

-- 
Pedro Alves

Re: [Cegcc-devel] limits.h not found

[Dave K. <dav...@go...>]

On 31/01/2010 16:39, Pedro Alves wrote:

> These look pretty busted though:
> 
> --- /opt/mingw32ce-0.59/arm-mingw32ce/include/windef.h  2010-01-31 15:10:18.000000000 +0000
> +++ /opt/mingw32ce-0.59/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/windef.h      2010-01-31 15:21:19.000000000 +0000
> :
> :
> -#ifndef WIN32
> +#ifndef __WIN32__
>  #define WIN32
>  #endif

  This seems a strange thing to have in the first place; if WIN32 isn't
defined when you try and include a windows header, you're not compiling on a
windows system and should error, shouldn't you?  Might be simplest to remove
that clause from windef.h altogether, given the compiler always defines WIN32.

> -#ifndef _fastcall
> +#ifndef __fastcall__
>  #define _fastcall __attribute__((fastcall))
>  #endif

  Likewise this one is built into the compiler's predefines.  Errm, only
incorrectly so:

> $ arm-mingw32ce-gcc -dM -E - < /dev/null | grep fast
> #define _fastcall __attribute__((__cdecl__))
> #define __fastcall __attribute__((__cdecl__))
>
> $

  LOL, that made me do a double-take.  Err?  Is this maybe deliberate because
(WAG) fastcall doesn't mean anything on CE or some such reason?

    cheers,
      DaveK

Re: [Cegcc-devel] Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

[Dave K. <dav...@go...>]

On 27/01/2010 00:54, Sébastien Lorquet wrote:

> The latest toolchain, that produces the bug, is at:
> http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100125.zip

  I downloaded this zip and unpacked it to C:\ on a WinXpSp2 machine, then ran

PATH C:\mingw32ce-4.1-20100125\cross41\bin;%PATH%

> Simplest test case:
>
> #include <windows.h>
> int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR
> inCmdLine, int inCmdShow)
> {
>     MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
>     return 0;
> }
>
> compiles fine under linux with both
> arm-mingw32ce-gcc test.c -o test.exe
> and
> arm-mingw32ce-gcc -g test.c -o test.exe
>
> But with my toolchain, cross compiled from linux to mingw32msvc, the second
> line fails.

  So... are we sure we're testing the same thing?  Because it worked fine for me:

C:\mingw32ce-4.1-20100125>dir
 Volume in drive C has no label.
 Volume Serial Number is 6857-454C

 Directory of C:\mingw32ce-4.1-20100125

31/01/2010  16:40    <DIR>          .
31/01/2010  16:40    <DIR>          ..
31/01/2010  16:37    <DIR>          cross41
31/01/2010  16:34               209 test.c
               1 File(s)            209 bytes
               3 Dir(s)  17,257,099,264 bytes free

C:\mingw32ce-4.1-20100125>type test.c
#include <windows.h>
int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR
inCmdLine, int inCmdShow)
{
    MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
    return 0;
}


C:\mingw32ce-4.1-20100125>arm-mingw32ce-gcc -g test.c -o test.exe

C:\mingw32ce-4.1-20100125>dir
 Volume in drive C has no label.
 Volume Serial Number is 6857-454C

 Directory of C:\mingw32ce-4.1-20100125

31/01/2010  16:40    <DIR>          .
31/01/2010  16:40    <DIR>          ..
31/01/2010  16:37    <DIR>          cross41
31/01/2010  16:34               209 test.c
31/01/2010  16:40            28,753 test.exe
               2 File(s)         28,962 bytes
               3 Dir(s)  17,257,066,496 bytes free

C:\mingw32ce-4.1-20100125>arm-mingw32ce-objdump -h test.exe

test.exe:     file format pei-arm-wince-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000788  00011000  00011000  00000400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000020  00012000  00012000  00000c00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        0000029c  00013000  00013000  00000e00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .debug_aranges 000000e0  00014000  00014000  00001200  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_pubnames 000001f9  00015000  00015000  00001400  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   000013b3  00016000  00016000  00001600  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_abbrev 00000682  00018000  00018000  00002a00  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   00000740  00019000  00019000  00003200  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_frame  00000258  0001a000  0001a000  00003a00  2**2
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_str    0000004e  0001b000  0001b000  00003e00  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_loc    00000646  0001c000  0001c000  00004000  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_ranges 00000070  0001d000  0001d000  00004800  2**0
                  CONTENTS, READONLY, DEBUGGING

C:\mingw32ce-4.1-20100125>


On 31/01/2010 11:32, Sébastien Lorquet wrote:

> According to the code, the incriminated lines are:
> 
>       /* Flag that this BFD uses long names, even though the format might
>          expect them to be off by default.  This won't directly affect the
>          format of any output BFD created from this one, but the information
>          can be used to decide what to do.  */
>       bfd_coff_set_long_section_names (abfd, TRUE);
>       memcpy (buf, hdr->s_name + 1, SCNNMLEN - 1);
>       buf[SCNNMLEN - 1] = '\0';
>       strindex = strtol (buf, &p, 10);
>       if (*p == '\0' && strindex >= 0)
>         {
>           strings = _bfd_coff_read_string_table (abfd);
>           if (strings == NULL)
>             return FALSE;
> *          /* FIXME: For extra safety, we should make sure that
>              strindex does not run us past the end, but right now we
>              don't know the length of the string table.  */
> *          strings += strindex;
>           name = (char *) bfd_alloc (abfd,
>                                      (bfd_size_type) *strlen (strings)* +
> 1);
>           if (name == NULL)
>             return FALSE;
>           strcpy (name, strings);
>         }


> (gdb) print *hdr
> $10 = {s_name = "/8976241", s_paddr = 0, s_vaddr = 0, s_size = 145, s_scnptr
> = 572, s_relptr = 0, s_lnnoptr = 0, s_nreloc = 0, s_nlnno = 0,  s_flags =
> 1108344832, s_align = 21807152, s_page = 20 '\024'}

  Now, this should be a section header from the input .o file (created
temporarily during compilation since not using --save-temps), and some of
those values look right, but the s_name, which is meant to be a decimal offset
into the string table (at the end of the .o file) is clearly nonsensical.
> 
> I don't know why the heck this happens, but the address out of bounds I get
> seems related to this FIXME .

  The FIXME is stating that it would be nice if we could detect this kind of
malformed input here, but we (for structural reasons) can't.  The problem has
to be either that the assembler generated a bogus .o file in the first place,
or that ld is somehow corrupting or misreading that section header.

  Since I can't reproduce this problem, can you try recompiling your testcase,
using --save-temps, and then show us the output of "arm-mingw32ce-objdump -h
test.o" ?

    cheers,
      DaveK

Re: [Cegcc-devel] limits.h not found

[Pedro A. <pe...@co...>]

On Sunday 31 January 2010 16:26:38, Dave Korn wrote:

> -#if defined(UNDER_CE) && defined(__arm__)
> +#if defined(__UNDER_CE__) && defined(__arm__)

> -#ifdef UNICODE
> +#ifdef __UNICODE__

>   Do those look sensible to you?  There could conceivably be some knock-on
> effect of having all the fixed headers for the first time.

Indeed.

Those look harmless, and could potentially be TRT when building
with strict standards.  Both UNDER_CE and UNICODE are builtin defines:

>arm-mingw32ce-gcc -dM -E - < /dev/null | grep UNICODE
#define UNICODE 1
#define _UNICODE 1
#define __UNICODE__ 1
#define __UNICODE 1

>arm-mingw32ce-gcc -ansi -dM -E - < /dev/null | grep UNICODE
#define _UNICODE 1
#define __UNICODE__ 1
#define __UNICODE 1

Or, maybe we should force the non-underscored versions
to be always present, given that these are "standard" Windows
defines.


These look pretty busted though:

--- /opt/mingw32ce-0.59/arm-mingw32ce/include/windef.h  2010-01-31 15:10:18.000000000 +0000
+++ /opt/mingw32ce-0.59/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/windef.h      2010-01-31 15:21:19.000000000 +0000
:
:
-#ifndef WIN32
+#ifndef __WIN32__
 #define WIN32
 #endif
:
-#ifndef _fastcall
+#ifndef __fastcall__
 #define _fastcall __attribute__((fastcall))
 #endif

I couldn't find yet where are the fixinclude rules that
cause all these changes.  (looking at these rules for the first time).

-- 
Pedro Alves

Re: [Cegcc-devel] investigations about arm-mingw32ce-ar.exe failure on i586-mingw32msvc host

[Sébastien L. <sq...@gm...>]

this will drive me nuts.

Adding a dummy.c file to the archive, containing a

char test_if_this_will_fix_the_problem; (or any name, of course ;) )

fixes the problem, and the file format invalid error disappears. This will
be a workaround, but we need to fix it.

Sebastien

Re: [Cegcc-devel] investigations about arm-mingw32ce-ar.exe failure on i586-mingw32msvc host

[Sébastien L. <sq...@gm...>]

A "working" archive file is also invalid according to my tool. I assume it
works because ld or other tools only look at the symbol table header.

Sebastien

[Cegcc-devel] investigations about arm-mingw32ce-ar.exe failure on i586-mingw32msvc host

[Sébastien L. <sq...@gm...>]

Hi,

see
https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2942499&group_id=173455

I investigated this one too. Same as the ld one , I can't understand why
this happens only in mingw and not in linux.

I made an ar file decoder to find who is right, together with this (
http://en.wikipedia.org/wiki/Ar_%28Unix%29#File_format_details ) description
of the ar file format.

Decoding an ar file made on linux, I get:

reading global header for C:\Documents and
Settings\squalyl\Bureau\difference\libloaderfs-madeonlinux.a
global header: !<arch>

global header ok
file name: /
this is the symbol lookup table
file mod timestamp: 1264948266
file oid: 0
file gid: 0
file mode: 0
file size: 122
magic 1 ok
magic 2 ok
skipping file contents (122 bytes)
file name: //
this is the extended file list
file mod timestamp:
file oid:
file gid:
file mode:
file size: 18
magic 1 ok
magic 2 ok
reading extended file name table (18 bytes)
file name: /0
file mod timestamp: 1264948266
file oid: 1000
file gid: 1000
file mode: 100644
file size: 3094
magic 1 ok
magic 2 ok
skipping file contents (3094 bytes)
EOF

This is clearly correct.

however, with the arm-mingw32ce-ar.exe (on i586-mingw32msvc host) compiled
one, I get:

reading global header for C:\Documents and
Settings\squalyl\Bureau\difference\libloaderfs.a
global header: !<arch>

global header ok
file name: /
this is the symbol lookup table
file mod timestamp: 244213345533
file oid: 197232
file gid: 666709
file mode: 10604430
file size: 122
magic 1 ok
magic 2 ok
skipping file contents (122 bytes)
file name: //
this is the extended file list
file mod timestamp:
file oid:
file gid:
file mode:
file size: 2576980379
magic 1 ok
magic 2 ok
invalid size, cannot continue: For input string: "2576980379"

wow. my file suddenly grew this much?
the stamp and ID looks random too.

So either the ar format has changed, or the generated files are invalid.

Using "arm-mingw32ce-ar.exe -r -s -D" does absolutely nothing, this is the
-D compiled archive:

reading global header for C:\Documents and
Settings\squalyl\Bureau\difference\libloaderfs.a
global header: !<arch>

global header ok
file name: /
this is the symbol lookup table
file mod timestamp: 244213345533
file oid: 197232
file gid: 666709
file mode: 10604430
file size: 122
magic 1 ok
magic 2 ok
skipping file contents (122 bytes)
file name: //
this is the extended file list
file mod timestamp:
file oid:
file gid:
file mode:
file size: 2576980379
magic 1 ok
magic 2 ok
invalid size, cannot continue: For input string: "2576980379"

For me these are uninitialized variables. What do you think of this?

Sebastien