Re: RFC: Cygwin 64 bit?

[Kai Tietz <ktietz70 at googlemail dot com>]

2012/1/19 Kai Tietz:
> 2012/1/19 Corinna Vinschen:
>> On Jan 19 14:25, Kai Tietz wrote:
>>> Hi,
>>>
>>> So I read me through the mail-archive to get an overview of discussion.
>>>
>>> 2012/1/19 JonY :
>>> > On 1/19/2012 20:38, Corinna Vinschen wrote:
>>> >> On Jan 19 12:21, Pedro Alves wrote:
>>> >>> On 01/19/2012 12:19 PM, Pedro Alves wrote:
>>> >>>>
>>> >>>> 1. is probably acceptable by gcc upstream. ?Googling around,
>>> >>>> I find precedent in other compilers for something like that.
>>> >>>
>>> >>> Obviously, I meant 4., the pragma.
>>> >>
>>> >> Understood. ?What I mean with "upstream" here is not gcc, though.
>>> >>
>>> >> Upstream is the Mingw64 project in the first place. ?Is it acceptable
>>> >> for Mingw64 to adapt the Windows header files to a LP64 compiler? ?And
>>> >> if so, which solution is preferred?
>>> >>
>>> >>
>>> >> Corinna
>>>
>>> Well, as more I think about the #pragma-approach vs abstracting types
>>> in platform-headers, I come to the conclusion that the latter might be
>>> the more sane approach here.
>>> By this switch, we might get in troubles for C++'s name mangling, for
>>> debugging info in some corner-cases, and such constency issues as
>>> shown in my first reply.
>>> So IMHO the way to go would be to abstract types in platform-headers
>>> for LP64/LLP64. ?Obviously our platform-headers are right now made for
>>> LLP64 and ILP32, as those are the official existing ABIs for IA
>>> Windows.
>>> So it is doable, and mingw-w64 would be willing to support such a request.
>>
>> Oh, good! ?I assume you read all of the thread so far? ?If we come to
>> a conclusion how to do it, I'd be willing to do the ground work.
>
> Great.
>
>> Did you see http://cygwin.com/ml/cygwin-developers/2012-01/msg00023.html?
>> The extra header file is one possible approach I can think of.
>>
>> Another way to do it would be to drop all `long' and `int' types in
>> favor of fixed-size types from stdint.h, int32_t and uint32_t.
>
> The stdint.h approach I would prefer here, as it is the most portable
> way IMHO. ?Using defines can lead easily to issues, especially in
> user-land.

Well, we might still need an extra-header for this, which defines
types for 'long32_t'.  As we need for LLP64 still the type 'long'.  We
need to abstract here also constant-numbers using L-postfix.  But this
issue we know already by Wine-folk.  So it is doable and would even
help to be more in synch to Wine-venture.

Another subject about cygwin going 64-bit.  What ABI you actual want
to use by default?  The sysv-ABI, or the ms-ABI?  As if you want to
use sysv-ABI,  we need additionally to mark any prototype in
platform-headers by attribute to use the ms-ABI.

Kai