On Thu, 9 Jun 2022 15:04:29 -0400 Ken Brown wrote: > On 6/9/2022 12:00 PM, Yaakov Selkowitz wrote: > > On Thu, 2022-06-09 at 17:23 +0200, Corinna Vinschen wrote: > >> 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? > > > > Highly recommended. > > OK, I'll make that change.
Isn't the _dll_crt0() code in dcrt0.cc also x86_64 specific? -- Takashi Yano <[email protected]>
