[PATCH] include: Always enable DECLSPEC_HOTPATCH for explicitly stdcall functions.

[Zebediah Figura]

On 04/07/18 01:31, Austin English wrote:
> On Tue, Jul 3, 2018, 02:09 Alex Henrie <alexhenrie24 at gmail.com
> <mailto:alexhenrie24 at gmail.com>> wrote:
> 
>     On Tue, Jul 3, 2018 at 11:02 AM Nikolay Sivov
>     <nsivov at codeweavers.com <mailto:nsivov at codeweavers.com>> wrote:
>     >
>     > On 07/03/2018 11:54 AM, Zebediah Figura wrote:
>     > > On 03/07/18 10:11, Zebediah Figura wrote:
>     > >> On 03/07/18 00:34, Alex Henrie wrote:
>     > >>> OK, I don't think this is going to work at all. After adding
>     > >>> __ms_hook_prologue__ to the definition of __stdcall, I get tons of
>     > >>> "warning: ‘ms_hook_prologue’ attribute does not apply to types".
>     > >>>
>     > >>> This makes me think that, at least for now, it's best to
>     continue to
>     > >>> add DECLSPEC_HOTPATCH on a case-by-case basis.
>     > >>>
>     > >>> -Alex
>     > >>>
>     > >>>
>     > >> This seems like it would be a GCC bug; it works with other
>     attributes
>     > >> and there's no architectural reason it can't work here.
>     > >>
>     > >>
>     > > I guess it's because of this:
>     > >
>     > > https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01635.html
>     > >
>     > > I'm not sure what to do about this. Perhaps only set it on
>     WINAPI rather
>     > > than __stdcall? Will that work everywhere?
>     >
>     > If we want that for methods too, then no, because of
>     > STDMETHODCALLTYPE/STDAPICALLTYPE. Also because of things like
>     WMIAPI or
>     > WINGDIPAPI.
> 
>     And you get the same warnings even if you only add
>     __ms_hook_prologue__ to WINAPI.
> 
>     The warning may well be a GCC bug, but even so, I don't think we'll be
>     able to put __ms_hook_prologue__ everywhere until long after it's been
>     fixed. For now it would be best to just add DECLSPEC_HOTPATCH to
>     GetDIBits etc.
> 
>     -Alex
> 
> 
> Is there a GCC bug filed? I don't think we'll see much progress if no
> one has reported it.
> 
> Once fixed, we could probably add a configure check to see if we get a
> warning or not, and enable it based on that check, a la how we handle
> checks for CFLAGS. (Though that won't help for functions that currently
> use it getting it enabled twice, I guess).
> 
> 
> 
> 

I've filed bug 86407:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407