RFC: Cygwin 64 bit?
JonY
jon_y@users.sourceforge.net
Wed Jan 18 09:26:00 GMT 2012
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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20120118/d1950740/attachment.sig>
More information about the Cygwin-developers
mailing list