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?


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".


Attachment: signature.asc
Description: OpenPGP digital signature


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