[PATCH 7/7] Cygwin: remove miscellaneous 32-bit code

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Jun 9 15:23:11 GMT 2022

On May 29 17:26, Ken Brown wrote:
> On 5/29/2022 9:39 AM, Jon Turney wrote:
> > On 26/05/2022 20:17, Ken Brown wrote:
> > >   winsup/cygwin/autoload.cc                | 136 -----------------------
> > 
> > Looks good.
> > 
> > I think that perhaps the stdcall decoration number n is unused on
> > x86_64, so can be removed also in a followup?
> Thanks, I missed that.
> Also, I guess most or all of the uses of __stdcall and __cdecl can be
> removed from the code.

Yes, that's right, given there's only one calling convention on 64 bit.

I have a minor objection in terms of this patch.

When implementing support for AMD64, there were basically 2 problems to
solve. One of them was to support 64 bit systems, the other one was to
support AMD64.  At that time, only IA-64 and AMD64 64 bit systems
existed, and since we never considered IA-64 to run Cygwin on, we
subsumed all 64 bit code paths under the __x86_64__ macro.

But should we *ever* support ARM64, as unlikely as it is, we have to
make sure to find all the places where the code is specificially AMD64.
That goes, for instance, for all places calling assembler code, or
for exception handling accessing CPU registers, etc.

I'm open to discussion, but I think the code being CPU-specific
should still be enclosed into #ifdef __x86_64__ brackets, with an
#else #error alternative.

Right?  Wrong?  Useless complication?


More information about the Cygwin-patches mailing list