This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
[This time with Kai CCed, sorry about that]
On Jan 19 14:48, Kai Tietz wrote:
> 2012/1/19 Kai Tietz:
> > 2012/1/19 Corinna Vinschen:
> >> 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
Oh, ok. I guess we should underscore this type so that we don't have
collisions, something like _ms_long_t, _ms_ulong_t. The ms should make
clear that we refer to the definition of long in the MS sense.
There's also the chicken-egg problem since we just don't *have* any
stdint.h file for 64 bit Cygwin yet. Fixable, but still...
> need to abstract here also constant-numbers using L-postfix. But this
Oh, right. I didn't think about that.
> 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.
I read about the ABIs for a while and I guess we should stick to the ms
ABI for simplicity. The sysv ABI can store a few more args in registers,
but the added complexity is kind of disheartening. I wonder if that
also would break RtlUnwind, for instance.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat