Win32AttachOperationRequest seems to be using global new?

[David Holmes]

 > Is this an intentional exception to the rule, or an oversight?

I think it is an oversight.

David

On 13/11/2024 12:20 am, Julian Waters wrote:
> Hi all,
> 
> Win32AttachOperationRequest is created via new, but doesn't specify a 
> custom new inside the class definition. The result seems to be that we 
> use global new on Windows:
> 
>    for (int i=0; i<max_enqueued_operations; i++) {
>      Win32AttachOperationRequest* op = new Win32AttachOperationRequest();
>        f1: b9 28 0d 00 00       mov    ecx,0xd28
>        f6: e8 00 00 00 00       call   fb <Win32AttachListener::init()+0x7b>
> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long)
> 
> Stepping away from gcc's objdump and using the Microsoft dumpbin 
> alongside cl.exe instead, the result is this:
> 
>    0000000000000264: B9 28 0D 00 00     mov         ecx,0D28h
>    0000000000000269: E8 00 00 00 00     call        ??2 at YAPEAX_K@Z
>    000000000000026E: 48 89 44 24 28     mov         qword ptr [rsp+28h],rax
>    0000000000000273: 48 83 7C 24 28 00  cmp         qword ptr [rsp+28h],0
>    0000000000000279: 74 11              je          000000000000028C
>    000000000000027B: 48 8B 4C 24 28     mov         rcx,qword ptr [rsp+28h]
>    0000000000000280: E8 00 00 00 00     call        ?? 
> 0Win32AttachOperationRequest@@QEAA at XZ
> 
> undname "??2 at YAPEAX_K@Z"
> Microsoft (R) C++ Name Undecorator
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
> Undecoration of :- "??2 at YAPEAX_K@Z"
> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)"
> 
> undname "??0Win32AttachOperationRequest@@QEAA at XZ"
> Microsoft (R) C++ Name Undecorator
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ"
> is :- "public: __cdecl 
> Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64"
> 
> Visual Studio, lacking the nm utility, obviously doesn't catch this. 
> What was more surprising is that the gcc Link Time check also fails to 
> catch it as well. I had to manually check the output of nm after an 
> unrelated failure and happened to stumble across the symbols _Znwy 
> and _ZdlPvy which both correspond to
> 
> operator new(unsigned long long)
> operator delete(void*, unsigned long long)
> 
> The delete can be ignored, it's the result of a bug on my experimental 
> branch (It was first discovered there, then I tested it on master). I'm 
> more interested about the new, since it seems to be violating a HotSpot 
> rule. Is this an intentional exception to the rule, or an oversight?
> 
> best regards,
> Julian