Ws2tcpip.h

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Ws2tcpip.h

Pavel Pavlov
For some reason in cegcc sdk some functions ifdefed this way:

#if (_WIN32_WINNT >= 0x0501)
void WSAAPI freeaddrinfo (struct addrinfo*);
int WSAAPI getaddrinfo (const char*,const char*,const struct addrinfo*,
                        struct addrinfo**);
int WSAAPI getnameinfo(const struct sockaddr*,socklen_t,char*,DWORD,
                       char*,DWORD,int);
...


Even though these are awailable as of Windows CE .NET 4.1 and later: http://msdn.microsoft.com/en-us/library/ms910263.aspx
Mobile 6 sdk doesn't have any ifdef's around them also, so I think this header needs to be modified.


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Danny Backx
On Tue, 2010-03-09 at 01:41 -0500, Pavel Pavlov wrote:

> For some reason in cegcc sdk some functions ifdefed this way:
>
> #if (_WIN32_WINNT >= 0x0501)
> void WSAAPI freeaddrinfo (struct addrinfo*);
> int WSAAPI getaddrinfo (const char*,const char*,const struct addrinfo*,
>        struct addrinfo**);
> int WSAAPI getnameinfo(const struct sockaddr*,socklen_t,char*,DWORD,
>       char*,DWORD,int);
> ...
>
>
> Even though these are awailable as of Windows CE .NET 4.1 and later: http://msdn.microsoft.com/en-us/library/ms910263.aspx
> Mobile 6 sdk doesn't have any ifdef's around them also, so I think this header needs to be modified.

Is it just that chunk that needs fixing ? Then I could change to

#if (_WIN32_WINNT >= 0x0501) || defined(_WIN32_WCE)

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


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Vincent Torri


On Sat, 13 Mar 2010, Danny Backx wrote:

> On Tue, 2010-03-09 at 01:41 -0500, Pavel Pavlov wrote:
>> For some reason in cegcc sdk some functions ifdefed this way:
>>
>> #if (_WIN32_WINNT >= 0x0501)
>> void WSAAPI freeaddrinfo (struct addrinfo*);
>> int WSAAPI getaddrinfo (const char*,const char*,const struct addrinfo*,
>>        struct addrinfo**);
>> int WSAAPI getnameinfo(const struct sockaddr*,socklen_t,char*,DWORD,
>>       char*,DWORD,int);
>> ...
>>
>>
>> Even though these are awailable as of Windows CE .NET 4.1 and later: http://msdn.microsoft.com/en-us/library/ms910263.aspx
>> Mobile 6 sdk doesn't have any ifdef's around them also, so I think this header needs to be modified.
>
> Is it just that chunk that needs fixing ? Then I could change to
>
> #if (_WIN32_WINNT >= 0x0501) || defined(_WIN32_WCE)

shouldn't the version of _WIN32_WCE be tested ?

Vincent Torri

>
> Danny
> --
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Cegcc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
>
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pavel Pavlov
> On Sat, 13 Mar 2010, Danny Backx wrote:
>
> > On Tue, 2010-03-09 at 01:41 -0500, Pavel Pavlov wrote:
> >> For some reason in cegcc sdk some functions ifdefed this way:
> >>
> >> #if (_WIN32_WINNT >= 0x0501)
> >> void WSAAPI freeaddrinfo (struct addrinfo*);
> >> int WSAAPI getaddrinfo (const char*,const char*,const struct
> addrinfo*,
> >>        struct addrinfo**);
> >> int WSAAPI getnameinfo(const struct sockaddr*,socklen_t,char*,DWORD,
> >>       char*,DWORD,int);
> >> ...
> >>
> >>
> >> Even though these are awailable as of Windows CE .NET 4.1 and later:
> http://msdn.microsoft.com/en-us/library/ms910263.aspx
> >> Mobile 6 sdk doesn't have any ifdef's around them also, so I think
> this header needs to be modified.
> >
> > Is it just that chunk that needs fixing ? Then I could change to
> >
> > #if (_WIN32_WINNT >= 0x0501) || defined(_WIN32_WCE)
>
> shouldn't the version of _WIN32_WCE be tested ?


Well, wince sdk from ms doesn't have any tests, msdn says that the api is available from ce.net 4.1 so probably that should be tested then.

Guys, just a side note... I need to build for qualcom's snapdragon but I have no idea what switches I need to use to enable suitable arm version. Is there a magic combination to make cegcc printout list of available target -mcpu and -march switches? Right now I go to cegcc sources and see list of defined cpu in the source code and try using them, but nothing works for me (invalid switch). I'll try to rebuild latest version and I'll see if I can use that. I tried to use it a while ago, but my binaries wouldn't run if built by that version of cegcc (I'm mostly doing some voice/video stuff and ffmpeg)

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Danny Backx
On Sun, 2010-03-14 at 03:22 -0400, Pavel Pavlov wrote:
> > shouldn't the version of _WIN32_WCE be tested ?
>
>
> Well, wince sdk from ms doesn't have any tests, msdn says that the api is available from ce.net 4.1 so probably that should be tested then.

Just applied a fix.

> Guys, just a side note... I need to build for qualcom's snapdragon but I have no idea what switches I need to use to enable suitable arm version. Is there a magic combination to make cegcc printout list of available target -mcpu and -march switches? Right now I go to cegcc sources and see list of defined cpu in the source code and try using them, but nothing works for me (invalid switch). I'll try to rebuild latest version and I'll see if I can use that. I tried to use it a while ago, but my binaries wouldn't run if built by that version of cegcc (I'm mostly doing some voice/video stuff and ffmpeg)

Not sure what you're asking. It's an ARM chip so the standard settings
should just work. You probably know that. So you must be asking for
something specific, but what ?

The gcc mailing list(s) may also be a good place to ask this question ..

        Danny

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


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pavel Pavlov
> On Sun, 2010-03-14 at 03:22 -0400, Pavel Pavlov wrote:

> > > shouldn't the version of _WIN32_WCE be tested ?
> >
> >
> > Well, wince sdk from ms doesn't have any tests, msdn says that the
> api is available from ce.net 4.1 so probably that should be tested
> then.
>
> Just applied a fix.
>
> > Guys, just a side note... I need to build for qualcom's snapdragon
> but I have no idea what switches I need to use to enable suitable arm
> version. Is there a magic combination to make cegcc printout list of
> available target -mcpu and -march switches? Right now I go to cegcc
> sources and see list of defined cpu in the source code and try using
> them, but nothing works for me (invalid switch). I'll try to rebuild
> latest version and I'll see if I can use that. I tried to use it a
> while ago, but my binaries wouldn't run if built by that version of
> cegcc (I'm mostly doing some voice/video stuff and ffmpeg)
>
> Not sure what you're asking. It's an ARM chip so the standard settings
> should just work. You probably know that. So you must be asking for
> something specific, but what ?

Sorry, I should have give more info. Off course default vanilla armv4 will work, but I need to enable armv7 + neon compilation. Currently, It won't compile the code: error, unsupported ins for this arch. By the way, I have a few minor local changes in my copy related to coredll.dll vs coredll (see attachement).



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

coredll.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Danny Backx
On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> Sorry, I should have give more info. Off course default vanilla armv4 will work,
> but I need to enable armv7 + neon compilation. Currently, It won't compile the
> code: error, unsupported ins for this arch.

arm-mingw32ce-gcc --target-help mentions a lot of options.

> By the way, I have a few minor local changes in my copy related to coredll.dll vs coredll (see attachement).

I looked in my mailing archive but I can't find info about this - but I
seem to remember that this has been brought up before.

What exactly is the problem this solves, and why haven't we applied this
fix before ?

        Danny

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


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pavel Pavlov
> On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> > Sorry, I should have give more info. Off course default vanilla armv4
> will work,
> > but I need to enable armv7 + neon compilation. Currently, It won't
> compile the
> > code: error, unsupported ins for this arch.
>
> arm-mingw32ce-gcc --target-help mentions a lot of options.


That's a standard switch that's mentioned in arm-mingw32ce-gcc --help. It doesn't mention anything on how to get list of supported target CPU's or arch's.

>
> > By the way, I have a few minor local changes in my copy related to
> coredll.dll vs coredll (see attachement).
>
> I looked in my mailing archive but I can't find info about this - but I
> seem to remember that this has been brought up before.
>
> What exactly is the problem this solves, and why haven't we applied
> this
> fix before ?

Well, for some reason it was all written as COREDLL instead of coredll.dll. That means that many binaries are linked to COREDLL (without .dll suffix). There is no such behavior with ms tools, they always link to coredll.dll. Moreover, as far as I remember the way loader works is this: if there is no COREDLL it will try to load coredll.exe then coredll.dll, which means that if somebody "maliciously" creates a \windows\coredll.exe then everything that links to coredll will fail to load. I didn't very that though, still I don't see a reason to link to coredll instead of coredll.dll (plus in the list of dependencies (depends.exe) I don't see multiple dependencies on coredll and coredll.dll at the same time.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Vincent Richomme
On Sun, 14 Mar 2010 20:15:51 -0400, Pavel Pavlov <[hidden email]>
wrote:

>> On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
>> > Sorry, I should have give more info. Off course default vanilla armv4
>> will work,
>> > but I need to enable armv7 + neon compilation. Currently, It won't
>> compile the
>> > code: error, unsupported ins for this arch.
>>
>> arm-mingw32ce-gcc --target-help mentions a lot of options.
>
>
> That's a standard switch that's mentioned in arm-mingw32ce-gcc --help.
It

> doesn't mention anything on how to get list of supported target CPU's or
> arch's.
>
>>
>> > By the way, I have a few minor local changes in my copy related to
>> coredll.dll vs coredll (see attachement).
>>
>> I looked in my mailing archive but I can't find info about this - but I
>> seem to remember that this has been brought up before.
>>
>> What exactly is the problem this solves, and why haven't we applied
>> this
>> fix before ?
>
> Well, for some reason it was all written as COREDLL instead of
> coredll.dll. That means that many binaries are linked to COREDLL
(without
> .dll suffix). There is no such behavior with ms tools, they always link
to
> coredll.dll. Moreover, as far as I remember the way loader works is
this:
> if there is no COREDLL it will try to load coredll.exe then coredll.dll,
> which means that if somebody "maliciously" creates a
\windows\coredll.exe
> then everything that links to coredll will fail to load. I didn't very
that
> though, still I don't see a reason to link to coredll instead of
> coredll.dll (plus in the list of dependencies (depends.exe) I don't see
> multiple dependencies on coredll and coredll.dll at the same time.

I have already reported that kind of things hundred times with no result
even on binutils mailing list...





------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Danny Backx
In reply to this post by Pavel Pavlov
On Sun, 2010-03-14 at 20:15 -0400, Pavel Pavlov wrote:

> > On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> > > Sorry, I should have give more info. Off course default vanilla armv4
> > will work,
> > > but I need to enable armv7 + neon compilation. Currently, It won't
> > compile the
> > > code: error, unsupported ins for this arch.
> >
> > arm-mingw32ce-gcc --target-help mentions a lot of options.
>
>
> That's a standard switch that's mentioned in arm-mingw32ce-gcc --help. It doesn't mention anything on how to get list of supported target CPU's or arch's.

Doesn't this bit help ?

        Danny


  Known ARM CPUs (for use with the -mcpu= and -mtune= options):
    cortex-m1, cortex-m3, cortex-r4f, cortex-r4, cortex-a9, cortex-a8,
    arm1156t2-s, mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s,
arm1136jf-s,
    arm1136j-s, arm1026ej-s, arm926ej-s, iwmmxt2, iwmmxt, xscale,
arm1022e,
    arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e, arm1020t,
    arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
arm9,
    arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, strongarm1110,
    strongarm1100, strongarm110, strongarm, arm810, arm8, arm7dmi,
arm7dm,
    arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720, arm710,
arm700i,
    arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600, arm60,
arm6,
    arm3, arm250, arm2

  Known ARM architectures (for use with the -march= option):
    iwmmxt2, iwmmxt, ep9312, armv7-m, armv7-r, armv7-a, armv7, armv6-m,
armv6t2,
    armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e, armv5t,
armv5,
    armv4t, armv4, armv3m, armv3, armv2a, armv2


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


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pavel Pavlov
> On Sun, 2010-03-14 at 20:15 -0400, Pavel Pavlov wrote:
> > > On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> > > > Sorry, I should have give more info. Off course default vanilla
> armv4
> > > will work,
> > > > but I need to enable armv7 + neon compilation. Currently, It
> won't
> > > compile the
> > > > code: error, unsupported ins for this arch.
> > >
> > > arm-mingw32ce-gcc --target-help mentions a lot of options.
> >
> >
> > That's a standard switch that's mentioned in arm-mingw32ce-gcc --
> help. It doesn't mention anything on how to get list of supported
> target CPU's or arch's.
>
> Doesn't this bit help ?
>
> Danny
>
>
>   Known ARM CPUs (for use with the -mcpu= and -mtune= options):
>     cortex-m1, cortex-m3, cortex-r4f, cortex-r4, cortex-a9, cortex-a8,
>     arm1156t2-s, mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s,
> arm1136jf-s,
>     arm1136j-s, arm1026ej-s, arm926ej-s, iwmmxt2, iwmmxt, xscale,
> arm1022e,
>     arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e, arm1020t,
>     arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
> arm9,
>     arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, strongarm1110,
>     strongarm1100, strongarm110, strongarm, arm810, arm8, arm7dmi,
> arm7dm,
>     arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720, arm710,
> arm700i,
>     arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600, arm60,
> arm6,
>     arm3, arm250, arm2
>
>   Known ARM architectures (for use with the -march= option):
>     iwmmxt2, iwmmxt, ep9312, armv7-m, armv7-r, armv7-a, armv7, armv6-m,
> armv6t2,
>     armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e, armv5t,
> armv5,
>     armv4t, armv4, armv3m, armv3, armv2a, armv2
>


Strange, I'm not getting this output (I tested with the 4.1.0 build) I was testing with 4.1.0, it was added in 4.4.0.
If you are using 4.4.0, can you test this code:

#include <windows.h>
int main(int argc, char **argv){
            return (long) &VirtualAlloc;
}

1) with -march=armv5te  (works ok)
2) with -march=armv7 (error: target CPU does not support ARM mode ?!?)
3) with -mcpu=cortex-a8 (Assembler messages: Error: cannot represent BFD_RELOC_ARM_MOVW relocation in this object file format)

Does it mean that there is no proper support for newer cpu's in the version of binutils that come with cegcc? Is it easier for me to upgrade?

PS: Cmd line used: arm-mingw32ce-gcc -c /tmp/test.c   -mcpu=cortex-a8
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Danny Backx
On Mon, 2010-03-15 at 13:09 -0400, Pavel Pavlov wrote:

> > On Sun, 2010-03-14 at 20:15 -0400, Pavel Pavlov wrote:
> > > > On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> > > > > Sorry, I should have give more info. Off course default vanilla
> > armv4
> > > > will work,
> > > > > but I need to enable armv7 + neon compilation. Currently, It
> > won't
> > > > compile the
> > > > > code: error, unsupported ins for this arch.
> > > >
> > > > arm-mingw32ce-gcc --target-help mentions a lot of options.
> > >
> > >
> > > That's a standard switch that's mentioned in arm-mingw32ce-gcc --
> > help. It doesn't mention anything on how to get list of supported
> > target CPU's or arch's.
> >
> > Doesn't this bit help ?
> >
> > Danny
> >
> >
> >   Known ARM CPUs (for use with the -mcpu= and -mtune= options):
> >     cortex-m1, cortex-m3, cortex-r4f, cortex-r4, cortex-a9, cortex-a8,
> >     arm1156t2-s, mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s,
> > arm1136jf-s,
> >     arm1136j-s, arm1026ej-s, arm926ej-s, iwmmxt2, iwmmxt, xscale,
> > arm1022e,
> >     arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e, arm1020t,
> >     arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
> > arm9,
> >     arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, strongarm1110,
> >     strongarm1100, strongarm110, strongarm, arm810, arm8, arm7dmi,
> > arm7dm,
> >     arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720, arm710,
> > arm700i,
> >     arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600, arm60,
> > arm6,
> >     arm3, arm250, arm2
> >
> >   Known ARM architectures (for use with the -march= option):
> >     iwmmxt2, iwmmxt, ep9312, armv7-m, armv7-r, armv7-a, armv7, armv6-m,
> > armv6t2,
> >     armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e, armv5t,
> > armv5,
> >     armv4t, armv4, armv3m, armv3, armv2a, armv2
> >
>
>
> Strange, I'm not getting this output (I tested with the 4.1.0 build) I was testing with 4.1.0, it was added in 4.4.0.
> If you are using 4.4.0, can you test this code:
>
> #include <windows.h>
> int main(int argc, char **argv){
>    return (long) &VirtualAlloc;
> }
>
> 1) with -march=armv5te  (works ok)
> 2) with -march=armv7 (error: target CPU does not support ARM mode ?!?)
> 3) with -mcpu=cortex-a8 (Assembler messages: Error: cannot represent BFD_RELOC_ARM_MOVW relocation in this object file format)
>
> Does it mean that there is no proper support for newer cpu's in the version of binutils that come with cegcc? Is it easier for me to upgrade?
>
> PS: Cmd line used: arm-mingw32ce-gcc -c /tmp/test.c   -mcpu=cortex-a8

I get the same errors.

I don't think it's binutils : when running these commands with -v, the
program that gives the errors is the C compiler itself, see below.

Not sure what's going on.

        Danny

pavilion: {12} arm-mingw32ce-gcc -march=armv7 -o va-armv7.exe va.c -v
Using built-in specs.
Target: arm-mingw32ce
Configured
with: /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-4.4.0/configure --with-gcc --with-gnu-ld --with-gnu-as --build=i686-pc-linux-gnu --target=arm-mingw32ce --host=i686-pc-linux-gnu --prefix=/opt/mingw32ce --enable-threads=win32 --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-multilib --disable-interwork --without-newlib --enable-checking --with-headers --disable-__cxa_atexit
Thread model: win32
gcc version 4.4.0 (GCC)
COLLECT_GCC_OPTIONS='-march=armv7' '-o' 'va-armv7.exe' '-v'
 /opt/mingw32ce/libexec/gcc/arm-mingw32ce/4.4.0/cc1 -quiet -v
-D__COREDLL__ -D__MINGW32__ -D__MINGW32CE__ -D__CEGCC_VERSION__
-idirafter ../include/w32api -idirafter ../../include/w32api va.c -quiet
-dumpbase va.c -march=armv7 -auxbase va -version -o /tmp/ccCHQwYd.s
ignoring nonexistent directory
"/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/sys-include"
ignoring nonexistent directory "../include/w32api"
ignoring nonexistent directory "../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include
 /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed
 /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/include
End of search list.
va.c:1: error: target CPU does not support ARM mode
GNU C (GCC) version 4.4.0 (arm-mingw32ce)
        compiled by GNU C version 4.4.1, GMP version 4.3.2, MPFR version
2.4.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
pavilion: {13}


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


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pedro Alves-5
On Monday 15 March 2010 19:33:41, Danny Backx wrote:
> > 3) with -mcpu=cortex-a8 (Assembler messages: Error: cannot represent BFD_RELOC_ARM_MOVW relocation in this object file format)
> >
> > Does it mean that there is no proper support for newer cpu's in the version of binutils that come with cegcc? Is it easier for me to upgrade?
> >
> > PS: Cmd line used: arm-mingw32ce-gcc -c /tmp/test.c   -mcpu=cortex-a8
>

This device is a thumb-2 device.  Those are new relocations for forming
constants from immediates (usually using the movw/movt instruction
pair), rather than loading the data from the constant pool.  Although
these are static relocations, PE/COFF doesn't support
representing them in the .o files.  The easiest way around this is
disabling these instructions in gcc.  A better solution would be
to extend bfd and to have a way to represent these relocations,
as a GNU extension.  Perhaps a new section, or perhaps extend
the pseudo-relocs concept to static relocations (if we
need extra relocations in final images, new pseudo-reloc
kinds are the obvious choice).  An even better solution
would be for Microsoft to define and officialize new
relocations for Thumb2, but, probably not going to happen.

There are simple hooks for disabling those instructions under
gcc/config/arm.  That said, which that issue out of the way,
MSFT's compilers doesn't support thumb2 AFAIK.  So, even if the
code compiles, you're probably going to run into kernel
issues running it.

--
Pedro Alves

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pavel Pavlov
In reply to this post by Danny Backx
> On Mon, 2010-03-15 at 13:09 -0400, Pavel Pavlov wrote:
> > If you are using 4.4.0, can you test this code:
> >
> > #include <windows.h>
> > int main(int argc, char **argv){
> >    return (long) &VirtualAlloc;
> > }
> >
> > 1) with -march=armv5te  (works ok)
> > 2) with -march=armv7 (error: target CPU does not support ARM mode
> ?!?)
> > 3) with -mcpu=cortex-a8 (Assembler messages: Error: cannot represent
> BFD_RELOC_ARM_MOVW relocation in this object file format)
> >
> > Does it mean that there is no proper support for newer cpu's in the
> version of binutils that come with cegcc? Is it easier for me to
> upgrade?
> >
> > PS: Cmd line used: arm-mingw32ce-gcc -c /tmp/test.c   -mcpu=cortex-a8
>
> I get the same errors.
>
> I don't think it's binutils : when running these commands with -v, the
> program that gives the errors is the C compiler itself, see below.
>
> Not sure what's going on.
>
> Danny
>
> pavilion: {12} arm-mingw32ce-gcc -march=armv7 -o va-armv7.exe va.c -v
> Using built-in specs.
> Target: arm-mingw32ce
> Configured
> with: /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-
> 4.4.0/configure --with-gcc --with-gnu-ld --with-gnu-as --build=i686-pc-
> linux-gnu --target=arm-mingw32ce --host=i686-pc-linux-gnu --
> prefix=/opt/mingw32ce --enable-threads=win32 --disable-nls --enable-
> languages=c,c++ --disable-win32-registry --disable-multilib --disable-
> interwork --without-newlib --enable-checking --with-headers --disable-
> __cxa_atexit
> Thread model: win32
> gcc version 4.4.0 (GCC)
> COLLECT_GCC_OPTIONS='-march=armv7' '-o' 'va-armv7.exe' '-v'
>  /opt/mingw32ce/libexec/gcc/arm-mingw32ce/4.4.0/cc1 -quiet -v
> -D__COREDLL__ -D__MINGW32__ -D__MINGW32CE__ -D__CEGCC_VERSION__
> -idirafter ../include/w32api -idirafter ../../include/w32api va.c -
> quiet
> -dumpbase va.c -march=armv7 -auxbase va -version -o /tmp/ccCHQwYd.s
> ignoring nonexistent directory
> "/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-
> mingw32ce/sys-include"
> ignoring nonexistent directory "../include/w32api"
> ignoring nonexistent directory "../../include/w32api"
> #include "..." search starts here:
> #include <...> search starts here:
>  /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include
>  /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed
>  /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-
> mingw32ce/include
> End of search list.
> va.c:1: error: target CPU does not support ARM mode
> GNU C (GCC) version 4.4.0 (arm-mingw32ce)
>         compiled by GNU C version 4.4.1, GMP version 4.3.2, MPFR
> version
> 2.4.2.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> pavilion: {13}
>

In case of -mcpu=cortex-a8 the error comes from "GNU assembler version 2.20.51 (arm-mingw32ce) using BFD version (GNU Binutils) 2.20.51.20091016"
By the way, before complaining on the list I tried to fix the problem myself. For that, I downloaded latest gcc release (4.4.3), merged all the changes that were made in cegcc to 4.4.0 and used 4.4.3 instead of 4.4.0. It builds ok, but the errors I'm getting are the same (in cortex-a8 and armv7/armv7-a). If anybody interested to try, I can send the diff from 4.4.3

I see there is some debate about some problem related to statics. You remember the infamous problem when dll compiled with cegcc weren’t loading? This time it's all opposite: dll compiled with cegcc-4.4.0 works as-is on the device, but if it's compressed then it crashes. Initially, I didn't even think it had anything to do with upx itself (I set upx to be part of the build and I forgot that I use it), but then to make it easier to debug the problem I decided to debug uncompressed dll and strangely the problem disappeared if dll isn't upx compressed. Anyways, I decided to trace the problem and it was related to const static variable used.
I tried to create a simple test dll with the same type of code, but it doesn't produce unexpected behavior if it's a simple dll compressed by upx.
Basically, the code was like that:
const static AVClass av_codec_context_class = { "AVCodecContext", context_to_name, options };
Dllexport void test(){
        //approximate code, in reality I printed to log, here the code is just an example and doesn't convert to wide string.
        MessageBox(0, av_codec_context_class.class_name, L"", 0); // av_codec_context_class.class_name is "AVCodecContext"
}

The message box code would crash or show garbage when it tried to access av_codec_context_class.class_name, but if I removed const static from av_codec_context_class then the problem would go away.
I had to do some code related to custom loaders and I know in general what upx does when dll is loaded, knowing that... I really have doubts that it has anything to do with upx, most likely it just works with uncompressed dlls by surprise :)
Basically, upx works this way: it keeps the same image size (ram required for loading of the dll), then inside dllmain (dll entry point) it uncompresses the image into allocated ram, then it processes imports section and sets imported function pointers. Overall, it should result in physically the same layout in the memory after upx finishes running
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pavel Pavlov
In reply to this post by Pedro Alves-5


> -----Original Message-----
> From: Pedro Alves [mailto:[hidden email]]
> Sent: March 15, 2010 15:46
> To: [hidden email]; [hidden email]
> Cc: Pavel Pavlov
> Subject: Re: [Cegcc-devel] Ws2tcpip.h
>
> On Monday 15 March 2010 19:33:41, Danny Backx wrote:
> > > 3) with -mcpu=cortex-a8 (Assembler messages: Error: cannot
> represent BFD_RELOC_ARM_MOVW relocation in this object file format)
> > >
> > > Does it mean that there is no proper support for newer cpu's in the
> version of binutils that come with cegcc? Is it easier for me to
> upgrade?
> > >
> > > PS: Cmd line used: arm-mingw32ce-gcc -c /tmp/test.c   -mcpu=cortex-
> a8
> >
>
> This device is a thumb-2 device.  Those are new relocations for forming
> constants from immediates (usually using the movw/movt instruction
> pair), rather than loading the data from the constant pool.  Although
> these are static relocations, PE/COFF doesn't support
> representing them in the .o files.  The easiest way around this is
> disabling these instructions in gcc.  A better solution would be
> to extend bfd and to have a way to represent these relocations,
> as a GNU extension.  Perhaps a new section, or perhaps extend
> the pseudo-relocs concept to static relocations (if we
> need extra relocations in final images, new pseudo-reloc
> kinds are the obvious choice).  An even better solution
> would be for Microsoft to define and officialize new
> relocations for Thumb2, but, probably not going to happen.
>
> There are simple hooks for disabling those instructions under
> gcc/config/arm.  That said, which that issue out of the way,
> MSFT's compilers doesn't support thumb2 AFAIK.  So, even if the
> code compiles, you're probably going to run into kernel
> issues running it.
>

But I'm not building for thumb, on the contrary, that code I'm compiling is performance sensitive and I don't want to use thumb at all.
MS compilers are way behind gcc in this regard, the latest what they support is armv5e. But it doesn't mean that you can't use instructions supported by the CPU, right? How is that I'd have kernel issues then? The same way, I used arm6 code and it all worked without problems, this time I want to try to compile some code for snapdragon cpu (I have a couple devices), but it seems like gcc won't compile anything for the new instruction set.
By the way... I don't really understand the details you provided regarding relocations. To me, when there is a dllimport function used, then in some imports section linker places a pointer to that function. That pointer is set by the loader at load time. Overall, the code:

#include <windows.h>
int main(int argc, char **argv){
    return (long) &VirtualAlloc;
}

In my understanding is identical to:

static volatile const void * const __imp_VirtualAlloc;
int main(int argc, char **argv){
    return (long) __imp_VirtualAlloc;
}

Test confirms, that it returns the same error. Can I somehow completely disable thumb/thumb2 and only use regular arm 32-bit instructions plus neon/simd instructions (the ones that I need to execute)

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ws2tcpip.h

Pavel Pavlov
> But I'm not building for thumb, on the contrary, that code I'm
> compiling is performance sensitive and I don't want to use thumb at
> all.
> MS compilers are way behind gcc in this regard, the latest what they
> support is armv5e. But it doesn't mean that you can't use instructions
> supported by the CPU, right? How is that I'd have kernel issues then?
> The same way, I used arm6 code and it all worked without problems, this
> time I want to try to compile some code for snapdragon cpu (I have a
> couple devices), but it seems like gcc won't compile anything for the
> new instruction set.
> By the way... I don't really understand the details you provided
> regarding relocations. To me, when there is a dllimport function used,
> then in some imports section linker places a pointer to that function.
> That pointer is set by the loader at load time. Overall, the code:
>
> #include <windows.h>
> int main(int argc, char **argv){
>     return (long) &VirtualAlloc;
> }
>
> In my understanding is identical to:
>
> static volatile const void * const __imp_VirtualAlloc;
> int main(int argc, char **argv){
>     return (long) __imp_VirtualAlloc;
> }
>
> Test confirms, that it returns the same error. Can I somehow completely
> disable thumb/thumb2 and only use regular arm 32-bit instructions plus
> neon/simd instructions (the ones that I need to execute)
>


By the way, I didn't want to use cegcc 4.4.0 for one other reason also: it produced bigger binary. I wanted to actually check what's going on, it's not some 10% increase, it's more like 200% increase in my case. Stripped avcodec.dll went from 1.8 to 4.5 MB. I checked contents of each of the sections... and guess what, one of the sections is full of zeroes (it has a bit of data at the beginning and the rest is zeroes); the size of that section is 2.4MB. Is that normal with latest gcc version??






------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel