This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
Hi,
my 5 cents for this thread.
2012/1/17 JonY <jon_y@users.sourceforge.net>:
> On 1/18/2012 04:26, Corinna Vinschen wrote:
>> On Jan 17 14:56, Christopher Faylor wrote:
>>> On Tue, Jan 17, 2012 at 06:22:42PM +0100, Corinna Vinschen wrote:
>>>> Hi Jon,
>>>>
>>>> On Jun 27 11:08, JonY wrote:
>>>>> Yes, using only the win32api headers is possible, see the --disable-crt
>>>>> option in the mingw-w64-headers configure. The headers are very much
>>>>> LLP64 though.
>>>>>
>>>>> Though mingw-w64-crt doesn't have this facility yet, it is possible to
>>>>> use only dlltool to build the stub w32api equivalent link libraries for
>>>>> win64 linking, but without mingw bits like libmingwex.
>>>>> [...]
>>>>> The hairy parts would be the LP64/LLP64 ABI difference. For now we need
>>>>> to decide which ABI to go with, the rest of the work will rest on this
>>>>> decision.
>>>>
>>>> Here's a question to warm up this age-old thread.
>>>>
>>>> Consider we would like to have Cygwin-64 being LP64, and consider we
>>>> would like to use the mingw64 headers and libs to build Cygwin.
>>>>
>>>> In that case, all mingw64 headers have a problem in conjunction with
>>>> a Cygwin 64 bit compiler: ?All definitions in the headers which are
>>>> based on 'long' or 'unsigned long' are wrong. ?All of them would have
>>>> to use 'int' or 'unsigned int' instead.
>>>>
>>>> So, here's my question: ?Would it be acceptable upstream to add changes
>>>> along the lines of this one, for instance, in winnt.h:
>>>>
>>>> ?#if defined (__CYGWIN__) && defined (__x86_64__)
>>>> ? ?typedef int LONG;
>>>> ?#else
>>>> ? ?typedef long LONG;
>>>> ?#endif
>>>>
>>>> ?
>>>
>>> I think it's very wrong to put understanding of __CYGWIN__ into w32api.
>>>
>>> I'm saying this without checking to see if it's already there because,
>>> if it is, that's not a justification, it's a bug.
>>
>> Windows headers in their current state as in Mingw32 and Mingw64 only
>> work for 32-bit compiler or LLP64 64-bit compilers. ?How do you manage
>> it so that they still work in conjunction with an LP64 compiler as the
>> 64-bit Cygwin compiler is supposed to be?
>>
>> There are three ways AFAICS, but all of them require to change the
>> header files:
>>
>> - As above.
>>
>> - Start every header with a redefinition of "long":
>>
>> ? #if defined (__CYGWIN__) && defined (__x86_64__)
>> ? # define long int
>> ? #endif
>> ? [...]
>> ? #if defined (__CYGWIN__) && defined (__x86_64__)
>> ? # undef long
>> ? #endif
To use here __CYGWIN__ as marker in platform-headers seems to me
wrong. But compiler defines for LP64 IIRC already __LP64__ makro (or
if it doesn't we could teach it to do so along with __LLP64__).
Redefining long has some disadvantages here too. It might make it
impossible to use 'long long' as type, and causes issues to describe
types like 'long double'. Well, the latter shouldn't happen very
often, if there at all any 'long double' types in platform-headers.
Maybe in midl stuff.
>> - Add a new target-independent pragma to GCC and add this to the headers:
>>
>> ? ? #pragma long_size (push, 4)
>> ? ? [...]
>> ? ? #pragma long_size (pop)
>>
>> ? or
>>
>> ? ? #pragma model64 (push, LLP64) // value one of LLP64, LP64, ILP64, SILP64
>> ? ? [...]
>> ? ? #pragma model64 (pop)
>>
>> I would prefer the latter.
Well, pragma approach looks more sane to me, but is of course for user
of platform-headers always challenging, as (s)he has to take care that
signature gets proper types on usage. But normally - IIUC - usage of
platform-headers by end-users is discuraged anyway.
About the pragma approach I see some interesting (and sadly not that
easy to abstract) issue about type-sanity.
Eg.
long foo (long *p)
{
#pragma long_size (push, 4)
*p = 0;
#pragma long_size(pop)
return *p;
}
Regards,
Kai