This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Cygwin 64 bit?


2012/1/18 JonY <jon_y@users.sourceforge.net>:
> On 1/18/2012 17:02, Kai Tietz wrote:
>> 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
>>
>
> Make it settable via GCC command line option only? -mlong-abi=4? At
> least the whole translation unit has the same "long".

Well, for C-code this might work.  But not for C++, as here types
become part of signatures.

Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]