[RFC PATCH v2 0/6] host: Support macOS 12

[RFC PATCH v2 0/6] host: Support macOS 12

[Philippe Mathieu-Daudé]

Few patches to be able to build QEMU on macOS 12 (Monterey).

This basically consists of adapting deprecated APIs. I am not
sure about these APIs, so tagging as RFC.

I couldn't succeed to adapt the Cocoa code.

CI job added to avoid bitrotting (ignoring the Objective C
deprecation warning).

Philippe Mathieu-Daudé (6):
  configure: Allow passing extra Objective C compiler flags
  audio/coreaudio: Remove a deprecation warning on macOS 12
  block/file-posix: Remove a deprecation warning on macOS 12
  hvf: Make hvf_get_segments() / hvf_put_segments() local
  hvf: Remove deprecated hv_vcpu_flush() calls
  gitlab-ci: Support macOS 12 via cirrus-run

 configure                         |  8 ++++++++
 meson.build                       |  5 +++++
 target/i386/hvf/vmx.h             |  2 --
 target/i386/hvf/x86hvf.h          |  2 --
 audio/coreaudio.c                 | 16 ++++++++++------
 block/file-posix.c                | 13 +++++++++----
 target/i386/hvf/x86_task.c        |  1 -
 target/i386/hvf/x86hvf.c          |  6 ++----
 .gitlab-ci.d/cirrus.yml           | 16 ++++++++++++++++
 .gitlab-ci.d/cirrus/macos-12.vars | 16 ++++++++++++++++
 10 files changed, 66 insertions(+), 19 deletions(-)
 create mode 100644 .gitlab-ci.d/cirrus/macos-12.vars

-- 
2.33.1

[PATCH v2 1/6] configure: Allow passing extra Objective C compiler flags

[Philippe Mathieu-Daudé]

We can pass C/CPP/LD flags via CFLAGS/CXXFLAGS/LDFLAGS environment
variables, or via configure --extra-cflags / --extra-cxxflags /
--extra-ldflags options. Provide similar behavior for Objective C:
use existing flags from $OBJCFLAGS, or passed via --extra-objcflags.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
Cc: Paolo Bonzini <pbonzini@redhat.com>

 configure   | 8 ++++++++
 meson.build | 5 +++++
 2 files changed, 13 insertions(+)

diff --git a/configure b/configure
index 030728d11e9..4cdde1eeb4b 100755
--- a/configure
+++ b/configure
@@ -288,6 +288,7 @@ done
 
 EXTRA_CFLAGS=""
 EXTRA_CXXFLAGS=""
+EXTRA_OBJCFLAGS=""
 EXTRA_LDFLAGS=""
 
 xen_ctrl_version="$default_feature"
@@ -400,9 +401,12 @@ for opt do
   --extra-cflags=*)
     EXTRA_CFLAGS="$EXTRA_CFLAGS $optarg"
     EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $optarg"
+    EXTRA_OBJCFLAGS="$EXTRA_OBJCFLAGS $optarg"
     ;;
   --extra-cxxflags=*) EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $optarg"
   ;;
+  --extra-objcflags=*) EXTRA_OBJCFLAGS="$EXTRA_OBJCFLAGS $optarg"
+  ;;
   --extra-ldflags=*) EXTRA_LDFLAGS="$EXTRA_LDFLAGS $optarg"
   ;;
   --enable-debug-info) debug_info="yes"
@@ -781,6 +785,8 @@ for opt do
   ;;
   --extra-cxxflags=*)
   ;;
+  --extra-objcflags=*)
+  ;;
   --extra-ldflags=*)
   ;;
   --enable-debug-info)
@@ -1332,6 +1338,7 @@ Advanced options (experts only):
   --objcc=OBJCC            use Objective-C compiler OBJCC [$objcc]
   --extra-cflags=CFLAGS    append extra C compiler flags CFLAGS
   --extra-cxxflags=CXXFLAGS append extra C++ compiler flags CXXFLAGS
+  --extra-objcflags=OBJCFLAGS append extra Objective C compiler flags OBJCFLAGS
   --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS
   --cross-cc-ARCH=CC       use compiler when building ARCH guest test cases
   --cross-cc-flags-ARCH=   use compiler flags when building ARCH guest tests
@@ -3864,6 +3871,7 @@ if test "$skip_meson" = no; then
   echo "[built-in options]" >> $cross
   echo "c_args = [$(meson_quote $CFLAGS $EXTRA_CFLAGS)]" >> $cross
   echo "cpp_args = [$(meson_quote $CXXFLAGS $EXTRA_CXXFLAGS)]" >> $cross
+  test -n "$objcc" && echo "objc_args = [$(meson_quote $OBJCFLAGS $EXTRA_OBJCFLAGS)]" >> $cross
   echo "c_link_args = [$(meson_quote $CFLAGS $LDFLAGS $EXTRA_CFLAGS $EXTRA_LDFLAGS)]" >> $cross
   echo "cpp_link_args = [$(meson_quote $CXXFLAGS $LDFLAGS $EXTRA_CXXFLAGS $EXTRA_LDFLAGS)]" >> $cross
   echo "[binaries]" >> $cross
diff --git a/meson.build b/meson.build
index c1b1db1e28c..eb8b560b103 100644
--- a/meson.build
+++ b/meson.build
@@ -3285,6 +3285,11 @@
                                                + ['-O' + get_option('optimization')]
                                                + (get_option('debug') ? ['-g'] : []))}
 endif
+if targetos == 'darwin'
+  summary_info += {'OBJCFLAGS':       ' '.join(get_option('objc_args')
+                                               + ['-O' + get_option('optimization')]
+                                               + (get_option('debug') ? ['-g'] : []))}
+endif
 link_args = get_option(link_language + '_link_args')
 if link_args.length() > 0
   summary_info += {'LDFLAGS':         ' '.join(link_args)}
-- 
2.33.1

[RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Philippe Mathieu-Daudé]

When building on macOS 12 we get:

  audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster' is deprecated: first deprecated in macOS 12.0 [-Werror,-Wdeprecated-declarations]
      kAudioObjectPropertyElementMaster
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      kAudioObjectPropertyElementMain
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5: note: 'kAudioObjectPropertyElementMaster' has been explicitly marked deprecated here
      kAudioObjectPropertyElementMaster API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain", macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0)) = kAudioObjectPropertyElementMain
      ^

Use kAudioObjectPropertyElementMain (define it to
kAudioObjectPropertyElementMaster on macOS < 12).

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 audio/coreaudio.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index d8a21d3e507..c836bc9dd37 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
     bool enabled;
 } coreaudioVoiceOut;
 
+#if !defined(MAC_OS_VERSION_12_0)
+#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
+#endif
+
 static const AudioObjectPropertyAddress voice_addr = {
     kAudioHardwarePropertyDefaultOutputDevice,
     kAudioObjectPropertyScopeGlobal,
-    kAudioObjectPropertyElementMaster
+    kAudioObjectPropertyElementMain
 };
 
 static OSStatus coreaudio_get_voice(AudioDeviceID *id)
@@ -69,7 +73,7 @@ static OSStatus coreaudio_get_framesizerange(AudioDeviceID id,
     AudioObjectPropertyAddress addr = {
         kAudioDevicePropertyBufferFrameSizeRange,
         kAudioDevicePropertyScopeOutput,
-        kAudioObjectPropertyElementMaster
+        kAudioObjectPropertyElementMain
     };
 
     return AudioObjectGetPropertyData(id,
@@ -86,7 +90,7 @@ static OSStatus coreaudio_get_framesize(AudioDeviceID id, UInt32 *framesize)
     AudioObjectPropertyAddress addr = {
         kAudioDevicePropertyBufferFrameSize,
         kAudioDevicePropertyScopeOutput,
-        kAudioObjectPropertyElementMaster
+        kAudioObjectPropertyElementMain
     };
 
     return AudioObjectGetPropertyData(id,
@@ -103,7 +107,7 @@ static OSStatus coreaudio_set_framesize(AudioDeviceID id, UInt32 *framesize)
     AudioObjectPropertyAddress addr = {
         kAudioDevicePropertyBufferFrameSize,
         kAudioDevicePropertyScopeOutput,
-        kAudioObjectPropertyElementMaster
+        kAudioObjectPropertyElementMain
     };
 
     return AudioObjectSetPropertyData(id,
@@ -121,7 +125,7 @@ static OSStatus coreaudio_set_streamformat(AudioDeviceID id,
     AudioObjectPropertyAddress addr = {
         kAudioDevicePropertyStreamFormat,
         kAudioDevicePropertyScopeOutput,
-        kAudioObjectPropertyElementMaster
+        kAudioObjectPropertyElementMain
     };
 
     return AudioObjectSetPropertyData(id,
@@ -138,7 +142,7 @@ static OSStatus coreaudio_get_isrunning(AudioDeviceID id, UInt32 *result)
     AudioObjectPropertyAddress addr = {
         kAudioDevicePropertyDeviceIsRunning,
         kAudioDevicePropertyScopeOutput,
-        kAudioObjectPropertyElementMaster
+        kAudioObjectPropertyElementMain
     };
 
     return AudioObjectGetPropertyData(id,
-- 
2.33.1

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Akihiko Odaki]

On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
> When building on macOS 12 we get:
> 
>    audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster' is deprecated: first deprecated in macOS 12.0 [-Werror,-Wdeprecated-declarations]
>        kAudioObjectPropertyElementMaster
>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>        kAudioObjectPropertyElementMain
>    /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5: note: 'kAudioObjectPropertyElementMaster' has been explicitly marked deprecated here
>        kAudioObjectPropertyElementMaster API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain", macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0)) = kAudioObjectPropertyElementMain
>        ^
> 
> Use kAudioObjectPropertyElementMain (define it to
> kAudioObjectPropertyElementMaster on macOS < 12).
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>   audio/coreaudio.c | 16 ++++++++++------
>   1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
> index d8a21d3e507..c836bc9dd37 100644
> --- a/audio/coreaudio.c
> +++ b/audio/coreaudio.c
> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
>       bool enabled;
>   } coreaudioVoiceOut;
>   
> +#if !defined(MAC_OS_VERSION_12_0)
> +#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> +#endif
> +

Semantically MAC_OS_VERSION_12_0 defines the numeric value of version 
12.0 and its existence does not mean that 
kAudioObjectPropertyElementMain is defined. I suggest the following:
#if !__is_identifier(kAudioObjectPropertyElementMain)
#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
#endif

Regards,
Akihiko Odaki

>   static const AudioObjectPropertyAddress voice_addr = {
>       kAudioHardwarePropertyDefaultOutputDevice,
>       kAudioObjectPropertyScopeGlobal,
> -    kAudioObjectPropertyElementMaster
> +    kAudioObjectPropertyElementMain
>   };
>   
>   static OSStatus coreaudio_get_voice(AudioDeviceID *id)
> @@ -69,7 +73,7 @@ static OSStatus coreaudio_get_framesizerange(AudioDeviceID id,
>       AudioObjectPropertyAddress addr = {
>           kAudioDevicePropertyBufferFrameSizeRange,
>           kAudioDevicePropertyScopeOutput,
> -        kAudioObjectPropertyElementMaster
> +        kAudioObjectPropertyElementMain
>       };
>   
>       return AudioObjectGetPropertyData(id,
> @@ -86,7 +90,7 @@ static OSStatus coreaudio_get_framesize(AudioDeviceID id, UInt32 *framesize)
>       AudioObjectPropertyAddress addr = {
>           kAudioDevicePropertyBufferFrameSize,
>           kAudioDevicePropertyScopeOutput,
> -        kAudioObjectPropertyElementMaster
> +        kAudioObjectPropertyElementMain
>       };
>   
>       return AudioObjectGetPropertyData(id,
> @@ -103,7 +107,7 @@ static OSStatus coreaudio_set_framesize(AudioDeviceID id, UInt32 *framesize)
>       AudioObjectPropertyAddress addr = {
>           kAudioDevicePropertyBufferFrameSize,
>           kAudioDevicePropertyScopeOutput,
> -        kAudioObjectPropertyElementMaster
> +        kAudioObjectPropertyElementMain
>       };
>   
>       return AudioObjectSetPropertyData(id,
> @@ -121,7 +125,7 @@ static OSStatus coreaudio_set_streamformat(AudioDeviceID id,
>       AudioObjectPropertyAddress addr = {
>           kAudioDevicePropertyStreamFormat,
>           kAudioDevicePropertyScopeOutput,
> -        kAudioObjectPropertyElementMaster
> +        kAudioObjectPropertyElementMain
>       };
>   
>       return AudioObjectSetPropertyData(id,
> @@ -138,7 +142,7 @@ static OSStatus coreaudio_get_isrunning(AudioDeviceID id, UInt32 *result)
>       AudioObjectPropertyAddress addr = {
>           kAudioDevicePropertyDeviceIsRunning,
>           kAudioDevicePropertyScopeOutput,
> -        kAudioObjectPropertyElementMaster
> +        kAudioObjectPropertyElementMain
>       };
>   
>       return AudioObjectGetPropertyData(id,

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Philippe Mathieu-Daudé]

On 1/10/22 09:17, Akihiko Odaki wrote:
> On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
>> When building on macOS 12 we get:
>>
>>    audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
>> is deprecated: first deprecated in macOS 12.0
>> [-Werror,-Wdeprecated-declarations]
>>        kAudioObjectPropertyElementMaster
>>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>        kAudioObjectPropertyElementMain
>>   
>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5:
>> note: 'kAudioObjectPropertyElementMaster' has been explicitly marked
>> deprecated here
>>        kAudioObjectPropertyElementMaster
>> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
>> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
>> = kAudioObjectPropertyElementMain
>>        ^
>>
>> Use kAudioObjectPropertyElementMain (define it to
>> kAudioObjectPropertyElementMaster on macOS < 12).
>>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>>   audio/coreaudio.c | 16 ++++++++++------
>>   1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
>> index d8a21d3e507..c836bc9dd37 100644
>> --- a/audio/coreaudio.c
>> +++ b/audio/coreaudio.c
>> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
>>       bool enabled;
>>   } coreaudioVoiceOut;
>>   +#if !defined(MAC_OS_VERSION_12_0)
>> +#define kAudioObjectPropertyElementMain
>> kAudioObjectPropertyElementMaster
>> +#endif
>> +
> 
> Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
> 12.0 and its existence does not mean that
> kAudioObjectPropertyElementMain is defined. I suggest the following:
> #if !__is_identifier(kAudioObjectPropertyElementMain)
> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> #endif

OK, thank you!

> Regards,
> Akihiko Odaki

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Philippe Mathieu-Daudé]

On 1/10/22 09:44, Philippe Mathieu-Daudé wrote:
> On 1/10/22 09:17, Akihiko Odaki wrote:
>> On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
>>> When building on macOS 12 we get:
>>>
>>>    audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
>>> is deprecated: first deprecated in macOS 12.0
>>> [-Werror,-Wdeprecated-declarations]
>>>        kAudioObjectPropertyElementMaster
>>>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>        kAudioObjectPropertyElementMain
>>>   
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5:
>>> note: 'kAudioObjectPropertyElementMaster' has been explicitly marked
>>> deprecated here
>>>        kAudioObjectPropertyElementMaster
>>> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
>>> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
>>> = kAudioObjectPropertyElementMain
>>>        ^
>>>
>>> Use kAudioObjectPropertyElementMain (define it to
>>> kAudioObjectPropertyElementMaster on macOS < 12).
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>> ---
>>>   audio/coreaudio.c | 16 ++++++++++------
>>>   1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
>>> index d8a21d3e507..c836bc9dd37 100644
>>> --- a/audio/coreaudio.c
>>> +++ b/audio/coreaudio.c
>>> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
>>>       bool enabled;
>>>   } coreaudioVoiceOut;
>>>   +#if !defined(MAC_OS_VERSION_12_0)
>>> +#define kAudioObjectPropertyElementMain
>>> kAudioObjectPropertyElementMaster
>>> +#endif
>>> +
>>
>> Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
>> 12.0 and its existence does not mean that
>> kAudioObjectPropertyElementMain is defined. I suggest the following:
>> #if !__is_identifier(kAudioObjectPropertyElementMain)
>> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
>> #endif

Apparently __is_identifier() is Clang specific. It might be acceptable
since this file is restricted to macOS. Similarly for the other
block/file-posix.c patch, the section is conditional to  __APPLE__
being defined.

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Christian Schoenebeck]

On Montag, 10. Januar 2022 13:24:06 CET Philippe Mathieu-Daudé wrote:
> On 1/10/22 09:44, Philippe Mathieu-Daudé wrote:
> > On 1/10/22 09:17, Akihiko Odaki wrote:
> >> On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
> >>> When building on macOS 12 we get:
> >>> 
> >>>    audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
> >>> is deprecated: first deprecated in macOS 12.0
> >>> [-Werror,-Wdeprecated-declarations]
> >>>        kAudioObjectPropertyElementMaster
> >>>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>        kAudioObjectPropertyElementMain
> >>>   
> >>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frame
> >>> works/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5: note:
> >>> 'kAudioObjectPropertyElementMaster' has been explicitly marked
> >>> deprecated here
> >>>        kAudioObjectPropertyElementMaster
> >>> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
> >>> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
> >>> = kAudioObjectPropertyElementMain
> >>>        ^
> >>> 
> >>> Use kAudioObjectPropertyElementMain (define it to
> >>> kAudioObjectPropertyElementMaster on macOS < 12).
> >>> 
> >>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> >>> ---
> >>>   audio/coreaudio.c | 16 ++++++++++------
> >>>   1 file changed, 10 insertions(+), 6 deletions(-)
> >>> 
> >>> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
> >>> index d8a21d3e507..c836bc9dd37 100644
> >>> --- a/audio/coreaudio.c
> >>> +++ b/audio/coreaudio.c
> >>> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
> >>>       bool enabled;
> >>>   } coreaudioVoiceOut;
> >>>   +#if !defined(MAC_OS_VERSION_12_0)
> >>> +#define kAudioObjectPropertyElementMain
> >>> kAudioObjectPropertyElementMaster
> >>> +#endif
> >>> +
> >> 
> >> Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
> >> 12.0 and its existence does not mean that
> >> kAudioObjectPropertyElementMain is defined. I suggest the following:
> >> #if !__is_identifier(kAudioObjectPropertyElementMain)
> >> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> >> #endif
> 
> Apparently __is_identifier() is Clang specific. It might be acceptable
> since this file is restricted to macOS. Similarly for the other
> block/file-posix.c patch, the section is conditional to  __APPLE__
> being defined.

Correct, __is_identifier() is a clang extension and does not work with GCC
(tested). I would not use it. People on Mac usually use clang, but there are
also cross compilers for macOS binaries.

I'd suggest to use:

#if !defined(MAC_OS_VERSION_12_0) ||
    (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
#endif

Best regards,
Christian Schoenebeck

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Philippe Mathieu-Daudé]

On 1/10/22 14:07, Christian Schoenebeck wrote:
> On Montag, 10. Januar 2022 13:24:06 CET Philippe Mathieu-Daudé wrote:
>> On 1/10/22 09:44, Philippe Mathieu-Daudé wrote:
>>> On 1/10/22 09:17, Akihiko Odaki wrote:
>>>> On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
>>>>> When building on macOS 12 we get:
>>>>>
>>>>>    audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
>>>>> is deprecated: first deprecated in macOS 12.0
>>>>> [-Werror,-Wdeprecated-declarations]
>>>>>        kAudioObjectPropertyElementMaster
>>>>>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>        kAudioObjectPropertyElementMain
>>>>>   
>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frame
>>>>> works/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5: note:
>>>>> 'kAudioObjectPropertyElementMaster' has been explicitly marked
>>>>> deprecated here
>>>>>        kAudioObjectPropertyElementMaster
>>>>> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
>>>>> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
>>>>> = kAudioObjectPropertyElementMain
>>>>>        ^
>>>>>
>>>>> Use kAudioObjectPropertyElementMain (define it to
>>>>> kAudioObjectPropertyElementMaster on macOS < 12).
>>>>>
>>>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>>>> ---
>>>>>   audio/coreaudio.c | 16 ++++++++++------
>>>>>   1 file changed, 10 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
>>>>> index d8a21d3e507..c836bc9dd37 100644
>>>>> --- a/audio/coreaudio.c
>>>>> +++ b/audio/coreaudio.c
>>>>> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
>>>>>       bool enabled;
>>>>>   } coreaudioVoiceOut;
>>>>>   +#if !defined(MAC_OS_VERSION_12_0)
>>>>> +#define kAudioObjectPropertyElementMain
>>>>> kAudioObjectPropertyElementMaster
>>>>> +#endif
>>>>> +
>>>>
>>>> Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
>>>> 12.0 and its existence does not mean that
>>>> kAudioObjectPropertyElementMain is defined. I suggest the following:
>>>> #if !__is_identifier(kAudioObjectPropertyElementMain)
>>>> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
>>>> #endif
>>
>> Apparently __is_identifier() is Clang specific. It might be acceptable
>> since this file is restricted to macOS. Similarly for the other
>> block/file-posix.c patch, the section is conditional to  __APPLE__
>> being defined.
> 
> Correct, __is_identifier() is a clang extension and does not work with GCC
> (tested). I would not use it. People on Mac usually use clang, but there are
> also cross compilers for macOS binaries.
> 
> I'd suggest to use:
> 
> #if !defined(MAC_OS_VERSION_12_0) ||
>     (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> #endif

Uh I just posted v3. I didn't test GCC. I'll wait for more comment on v3
then repost v4 with your suggestion, thanks.

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Peter Maydell]

On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
> I'd suggest to use:
>
> #if !defined(MAC_OS_VERSION_12_0) ||
>     (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> #endif

This is also how we do this for existing checks of this sort,
like the one in osdep.h for qemu_thread_jit_execute().

-- PMM

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Akihiko Odaki]

On 2022/01/10 22:22, Peter Maydell wrote:
> On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
> <qemu_oss@crudebyte.com> wrote:
>> I'd suggest to use:
>>
>> #if !defined(MAC_OS_VERSION_12_0) ||
>>      (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
>> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
>> #endif
> 
> This is also how we do this for existing checks of this sort,
> like the one in osdep.h for qemu_thread_jit_execute().
> 
> -- PMM

If I understand correctly, Many macOS-specific codes already no longer 
complies with GCC because they depend on modern features GCC doesn't 
provide. The most problematic construction is block; it is extensively 
used by Apple's ABI and API and you cannot avoid using it even if you try.

Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of 
the supported version. The lower bound should be preferred here because 
the usage of the new identifier is applied regardless of the version of 
the host system. It is in contrary to the usage of 
MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are 
used only for the newer versions. The lower bound is defined as 
MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of the 
two macros because they have the same value in QEMU and 
kAudioObjectPropertyElementMain is a constant resolved compile-time, but 
it is still nice to have the code semantically correct.

Regards,
Akihiko Odaki

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Christian Schoenebeck]

On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
> On 2022/01/10 22:22, Peter Maydell wrote:
> > On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
> > 
> > <qemu_oss@crudebyte.com> wrote:
> >> I'd suggest to use:
> >> 
> >> #if !defined(MAC_OS_VERSION_12_0) ||
> >> 
> >>      (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
> >> 
> >> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> >> #endif
> > 
> > This is also how we do this for existing checks of this sort,
> > like the one in osdep.h for qemu_thread_jit_execute().
> > 
> > -- PMM
> 
> If I understand correctly, Many macOS-specific codes already no longer
> complies with GCC because they depend on modern features GCC doesn't
> provide. The most problematic construction is block; it is extensively
> used by Apple's ABI and API and you cannot avoid using it even if you try.

You mean Obj-C blocks? That's working with GCC for decades. I am not aware 
about any recent changes to Obj-C block mechanisms by Apple.

> Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of
> the supported version. The lower bound should be preferred here because
> the usage of the new identifier is applied regardless of the version of
> the host system. It is in contrary to the usage of
> MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
> used only for the newer versions. The lower bound is defined as
> MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of the
> two macros because they have the same value in QEMU and
> kAudioObjectPropertyElementMain is a constant resolved compile-time, but
> it is still nice to have the code semantically correct.

For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the correct one. 
This is about whether enum kAudioObjectPropertyElementMain is defined in the 
SDK header files. That's all. And the new enum kAudioObjectPropertyElementMain 
is pure refactoring of the enum's old name due to social reasons ("Master"). 
The actual reflected numeric value and semantic of the enum is unchanged and 
the resulting binary and behaviour are identical.

There are other cases where MAC_OS_X_VERSION_MIN_REQUIRED (a.k.a. "minimum 
deployment target") would be used instead: macOS APIs that might be available 
to only some, but not to the entire macOS version range officially supported 
by the rolled out binary. Did you see any particular case where this is 
incorrectly used in QEMU?

Best regards,
Christian Schoenebeck

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Akihiko Odaki]

On 2022/01/11 3:46, Christian Schoenebeck wrote:
> On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
>> On 2022/01/10 22:22, Peter Maydell wrote:
>>> On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
>>>
>>> <qemu_oss@crudebyte.com> wrote:
>>>> I'd suggest to use:
>>>>
>>>> #if !defined(MAC_OS_VERSION_12_0) ||
>>>>
>>>>       (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
>>>>
>>>> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
>>>> #endif
>>>
>>> This is also how we do this for existing checks of this sort,
>>> like the one in osdep.h for qemu_thread_jit_execute().
>>>
>>> -- PMM
>>
>> If I understand correctly, Many macOS-specific codes already no longer
>> complies with GCC because they depend on modern features GCC doesn't
>> provide. The most problematic construction is block; it is extensively
>> used by Apple's ABI and API and you cannot avoid using it even if you try.
> 
> You mean Obj-C blocks? That's working with GCC for decades. I am not aware
> about any recent changes to Obj-C block mechanisms by Apple.
> 
>> Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of
>> the supported version. The lower bound should be preferred here because
>> the usage of the new identifier is applied regardless of the version of
>> the host system. It is in contrary to the usage of
>> MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
>> used only for the newer versions. The lower bound is defined as
>> MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of the
>> two macros because they have the same value in QEMU and
>> kAudioObjectPropertyElementMain is a constant resolved compile-time, but
>> it is still nice to have the code semantically correct.
> 
> For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the correct one.
> This is about whether enum kAudioObjectPropertyElementMain is defined in the
> SDK header files. That's all. And the new enum kAudioObjectPropertyElementMain
> is pure refactoring of the enum's old name due to social reasons ("Master").
> The actual reflected numeric value and semantic of the enum is unchanged and
> the resulting binary and behaviour are identical.


There are a few problems with the usage of MAC_OS_X_VERSION_MAX_ALLOWED:
- The deprecation warning is designed to work with 
MAC_OS_X_VERSION_MIN_REQUIRED. You may verify that with:
cc -mmacosx-version-min=12.0 -x c - <<EOF
#include <CoreAudio/CoreAudio.h>

int main()
{
    int k = kAudioObjectPropertyElementMaster;
}
EOF
- The programmer must be aware whether it is constant or not.
- The macro tells about the runtime and not the SDK. There is no way to 
tell the SDK version and that is why I suggested __is_identifier at the 
first place. However, now I'm convinced that 
MAC_OS_X_VERSION_MIN_REQUIRED is the better option because of the above 
reasons.

> 
> There are other cases where MAC_OS_X_VERSION_MIN_REQUIRED (a.k.a. "minimum
> deployment target") would be used instead: macOS APIs that might be available
> to only some, but not to the entire macOS version range officially supported
> by the rolled out binary. Did you see any particular case where this is
> incorrectly used in QEMU?
> 
> Best regards,
> Christian Schoenebeck
> 
> 
Assuming the correctness of the use MAC_OS_X_VERSION_MAX_ALLOWED is 
irrelevant with the nature of the identifier (constant or not), the same 
problem is in ui/cocoa.m:
#ifndef MAC_OS_X_VERSION_10_13
#define MAC_OS_X_VERSION_10_13 101300
#endif

/* 10.14 deprecates NSOnState and NSOffState in favor of
  * NSControlStateValueOn/Off, which were introduced in 10.13.
  * Define for older versions
  */
#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_13
#define NSControlStateValueOn NSOnState
#define NSControlStateValueOff NSOffState
#endif

Regards,
Akihiko Odaki

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Peter Maydell]

On Mon, 10 Jan 2022 at 19:01, Akihiko Odaki <akihiko.odaki@gmail.com> wrote:
> Assuming the correctness of the use MAC_OS_X_VERSION_MAX_ALLOWED is
> irrelevant with the nature of the identifier (constant or not), the same
> problem is in ui/cocoa.m:
> #ifndef MAC_OS_X_VERSION_10_13
> #define MAC_OS_X_VERSION_10_13 101300
> #endif
>
> /* 10.14 deprecates NSOnState and NSOffState in favor of
>   * NSControlStateValueOn/Off, which were introduced in 10.13.
>   * Define for older versions
>   */
> #if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_13
> #define NSControlStateValueOn NSOnState
> #define NSControlStateValueOff NSOffState
> #endif

It's tempting to fix that one by just deleting the ifdeffery,
since cocoa.m already doesn't compile on 10.13 (it uses
NSPasteboardTypeOwner, which was only introduced in 10.14)...

-- PMM

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Christian Schoenebeck]

On Montag, 10. Januar 2022 20:01:40 CET Akihiko Odaki wrote:
> On 2022/01/11 3:46, Christian Schoenebeck wrote:
> > On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
> >> On 2022/01/10 22:22, Peter Maydell wrote:
> >>> On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
> >>> 
> >>> <qemu_oss@crudebyte.com> wrote:
> >>>> I'd suggest to use:
> >>>> 
> >>>> #if !defined(MAC_OS_VERSION_12_0) ||
> >>>> 
> >>>>       (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
> >>>> 
> >>>> #define kAudioObjectPropertyElementMain
> >>>> kAudioObjectPropertyElementMaster
> >>>> #endif
> >>> 
> >>> This is also how we do this for existing checks of this sort,
> >>> like the one in osdep.h for qemu_thread_jit_execute().
> >>> 
> >>> -- PMM
> >> 
> >> If I understand correctly, Many macOS-specific codes already no longer
> >> complies with GCC because they depend on modern features GCC doesn't
> >> provide. The most problematic construction is block; it is extensively
> >> used by Apple's ABI and API and you cannot avoid using it even if you
> >> try.
> > 
> > You mean Obj-C blocks? That's working with GCC for decades. I am not aware
> > about any recent changes to Obj-C block mechanisms by Apple.
> > 
> >> Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of
> >> the supported version. The lower bound should be preferred here because
> >> the usage of the new identifier is applied regardless of the version of
> >> the host system. It is in contrary to the usage of
> >> MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
> >> used only for the newer versions. The lower bound is defined as
> >> MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of the
> >> two macros because they have the same value in QEMU and
> >> kAudioObjectPropertyElementMain is a constant resolved compile-time, but
> >> it is still nice to have the code semantically correct.
> > 
> > For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the correct
> > one. This is about whether enum kAudioObjectPropertyElementMain is
> > defined in the SDK header files. That's all. And the new enum
> > kAudioObjectPropertyElementMain is pure refactoring of the enum's old
> > name due to social reasons ("Master"). The actual reflected numeric value
> > and semantic of the enum is unchanged and the resulting binary and
> > behaviour are identical.
> 
> There are a few problems with the usage of MAC_OS_X_VERSION_MAX_ALLOWED:
> - The deprecation warning is designed to work with
> MAC_OS_X_VERSION_MIN_REQUIRED. You may verify that with:
> cc -mmacosx-version-min=12.0 -x c - <<EOF
> #include <CoreAudio/CoreAudio.h>
> 
> int main()
> {
>     int k = kAudioObjectPropertyElementMaster;
> }
> EOF

That's actually interesting. On other projects I definitely saw deprecated 
warnings before on API declarations that were deprecated at a version higher 
than the project's minimum deployment target.

Did they change that?

> - The programmer must be aware whether it is constant or not.
> - The macro tells about the runtime and not the SDK. There is no way to
> tell the SDK version and that is why I suggested __is_identifier at the
> first place. However, now I'm convinced that
> MAC_OS_X_VERSION_MIN_REQUIRED is the better option because of the above
> reasons.

If you make it dependent on MAC_OS_X_VERSION_MIN_REQUIRED, people with older 
SDKs (e.g. Xcode <=13.0) would get a compiler error.

You are right about the deprecated warning not being emitted in the example 
above, currently not sure why, but I still think MAC_OS_X_VERSION_MAX_ALLOWED 
is the way to go in this case.

Best regards,
Christian Schoenebeck

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Akihiko Odaki]

On 2022/01/11 5:22, Christian Schoenebeck wrote:
> On Montag, 10. Januar 2022 20:01:40 CET Akihiko Odaki wrote:
>> On 2022/01/11 3:46, Christian Schoenebeck wrote:
>>> On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
>>>> On 2022/01/10 22:22, Peter Maydell wrote:
>>>>> On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
>>>>>
>>>>> <qemu_oss@crudebyte.com> wrote:
>>>>>> I'd suggest to use:
>>>>>>
>>>>>> #if !defined(MAC_OS_VERSION_12_0) ||
>>>>>>
>>>>>>        (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
>>>>>>
>>>>>> #define kAudioObjectPropertyElementMain
>>>>>> kAudioObjectPropertyElementMaster
>>>>>> #endif
>>>>>
>>>>> This is also how we do this for existing checks of this sort,
>>>>> like the one in osdep.h for qemu_thread_jit_execute().
>>>>>
>>>>> -- PMM
>>>>
>>>> If I understand correctly, Many macOS-specific codes already no longer
>>>> complies with GCC because they depend on modern features GCC doesn't
>>>> provide. The most problematic construction is block; it is extensively
>>>> used by Apple's ABI and API and you cannot avoid using it even if you
>>>> try.
>>>
>>> You mean Obj-C blocks? That's working with GCC for decades. I am not aware
>>> about any recent changes to Obj-C block mechanisms by Apple.
>>>
>>>> Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of
>>>> the supported version. The lower bound should be preferred here because
>>>> the usage of the new identifier is applied regardless of the version of
>>>> the host system. It is in contrary to the usage of
>>>> MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
>>>> used only for the newer versions. The lower bound is defined as
>>>> MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of the
>>>> two macros because they have the same value in QEMU and
>>>> kAudioObjectPropertyElementMain is a constant resolved compile-time, but
>>>> it is still nice to have the code semantically correct.
>>>
>>> For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the correct
>>> one. This is about whether enum kAudioObjectPropertyElementMain is
>>> defined in the SDK header files. That's all. And the new enum
>>> kAudioObjectPropertyElementMain is pure refactoring of the enum's old
>>> name due to social reasons ("Master"). The actual reflected numeric value
>>> and semantic of the enum is unchanged and the resulting binary and
>>> behaviour are identical.
>>
>> There are a few problems with the usage of MAC_OS_X_VERSION_MAX_ALLOWED:
>> - The deprecation warning is designed to work with
>> MAC_OS_X_VERSION_MIN_REQUIRED. You may verify that with:
>> cc -mmacosx-version-min=12.0 -x c - <<EOF
>> #include <CoreAudio/CoreAudio.h>
>>
>> int main()
>> {
>>      int k = kAudioObjectPropertyElementMaster;
>> }
>> EOF
> 
> That's actually interesting. On other projects I definitely saw deprecated
> warnings before on API declarations that were deprecated at a version higher
> than the project's minimum deployment target.
> 
> Did they change that?

I don't think so. The behavior is documented at:
https://clang.llvm.org/docs/AttributeReference.html#availability
and the example refers to OS X 10.4, 10.6, 10.7. Probably they haven't 
changed the behavior for decades.

MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/os/availability.h 
says manually defining API_TO_BE_DEPRECATED can alter the behavior so 
that may be the case.

> 
>> - The programmer must be aware whether it is constant or not.
>> - The macro tells about the runtime and not the SDK. There is no way to
>> tell the SDK version and that is why I suggested __is_identifier at the
>> first place. However, now I'm convinced that
>> MAC_OS_X_VERSION_MIN_REQUIRED is the better option because of the above
>> reasons.
> 
> If you make it dependent on MAC_OS_X_VERSION_MIN_REQUIRED, people with older
> SDKs (e.g. Xcode <=13.0) would get a compiler error.

__is_identifier is the only option if you need a compatibility with the 
older SDKs while specifying a greater version for 
MAC_OS_X_VERSION_MIN_REQUIRED. It also applies to 
MAC_OS_X_VERSION_MAX_ALLOWED; they give the possible runtime versions 
and not the SDK version.

> 
> You are right about the deprecated warning not being emitted in the example
> above, currently not sure why, but I still think MAC_OS_X_VERSION_MAX_ALLOWED
> is the way to go in this case.

The page and the header file I referred the above would help 
understanding the behavior.

Regards,
Akihiko Odaki

> 
> Best regards,
> Christian Schoenebeck
> 
> 

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Christian Schoenebeck]

On Montag, 10. Januar 2022 21:39:28 CET Akihiko Odaki wrote:
> On 2022/01/11 5:22, Christian Schoenebeck wrote:
> > On Montag, 10. Januar 2022 20:01:40 CET Akihiko Odaki wrote:
> >> On 2022/01/11 3:46, Christian Schoenebeck wrote:
> >>> On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
> >>>> On 2022/01/10 22:22, Peter Maydell wrote:
> >>>>> On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
> >>>>> 
> >>>>> <qemu_oss@crudebyte.com> wrote:
> >>>>>> I'd suggest to use:
> >>>>>> 
> >>>>>> #if !defined(MAC_OS_VERSION_12_0) ||
> >>>>>> 
> >>>>>>        (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
> >>>>>> 
> >>>>>> #define kAudioObjectPropertyElementMain
> >>>>>> kAudioObjectPropertyElementMaster
> >>>>>> #endif
> >>>>> 
> >>>>> This is also how we do this for existing checks of this sort,
> >>>>> like the one in osdep.h for qemu_thread_jit_execute().
> >>>>> 
> >>>>> -- PMM
> >>>> 
> >>>> If I understand correctly, Many macOS-specific codes already no longer
> >>>> complies with GCC because they depend on modern features GCC doesn't
> >>>> provide. The most problematic construction is block; it is extensively
> >>>> used by Apple's ABI and API and you cannot avoid using it even if you
> >>>> try.
> >>> 
> >>> You mean Obj-C blocks? That's working with GCC for decades. I am not
> >>> aware
> >>> about any recent changes to Obj-C block mechanisms by Apple.
> >>> 
> >>>> Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of
> >>>> the supported version. The lower bound should be preferred here because
> >>>> the usage of the new identifier is applied regardless of the version of
> >>>> the host system. It is in contrary to the usage of
> >>>> MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
> >>>> used only for the newer versions. The lower bound is defined as
> >>>> MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of
> >>>> the
> >>>> two macros because they have the same value in QEMU and
> >>>> kAudioObjectPropertyElementMain is a constant resolved compile-time,
> >>>> but
> >>>> it is still nice to have the code semantically correct.
> >>> 
> >>> For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the
> >>> correct
> >>> one. This is about whether enum kAudioObjectPropertyElementMain is
> >>> defined in the SDK header files. That's all. And the new enum
> >>> kAudioObjectPropertyElementMain is pure refactoring of the enum's old
> >>> name due to social reasons ("Master"). The actual reflected numeric
> >>> value
> >>> and semantic of the enum is unchanged and the resulting binary and
> >>> behaviour are identical.
> >> 
> >> There are a few problems with the usage of MAC_OS_X_VERSION_MAX_ALLOWED:
> >> - The deprecation warning is designed to work with
> >> MAC_OS_X_VERSION_MIN_REQUIRED. You may verify that with:
> >> cc -mmacosx-version-min=12.0 -x c - <<EOF
> >> #include <CoreAudio/CoreAudio.h>
> >> 
> >> int main()
> >> {
> >> 
> >>      int k = kAudioObjectPropertyElementMaster;
> >> 
> >> }
> >> EOF
> > 
> > That's actually interesting. On other projects I definitely saw deprecated
> > warnings before on API declarations that were deprecated at a version
> > higher than the project's minimum deployment target.
> > 
> > Did they change that?
> 
> I don't think so. The behavior is documented at:
> https://clang.llvm.org/docs/AttributeReference.html#availability
> and the example refers to OS X 10.4, 10.6, 10.7. Probably they haven't
> changed the behavior for decades.

The descriptions is very vague. It sais e.g. "If Clang is instructed to 
compile code for macOS 10.6 ...". So it is describing it only via singular 
version per example. We are talking about version ranges however.

> MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/os/availabilit
> y.h says manually defining API_TO_BE_DEPRECATED can alter the behavior so
> that may be the case.
> 
> >> - The programmer must be aware whether it is constant or not.
> >> - The macro tells about the runtime and not the SDK. There is no way to
> >> tell the SDK version and that is why I suggested __is_identifier at the
> >> first place. However, now I'm convinced that
> >> MAC_OS_X_VERSION_MIN_REQUIRED is the better option because of the above
> >> reasons.
> > 
> > If you make it dependent on MAC_OS_X_VERSION_MIN_REQUIRED, people with
> > older SDKs (e.g. Xcode <=13.0) would get a compiler error.
> 
> __is_identifier is the only option if you need a compatibility with the
> older SDKs while specifying a greater version for
> MAC_OS_X_VERSION_MIN_REQUIRED. It also applies to
> MAC_OS_X_VERSION_MAX_ALLOWED; they give the possible runtime versions
> and not the SDK version.

I have never used __is_identifier() for such things. I always used 
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED and it was 
always doing the job.

And for symbols: those are automatically weak linked by the compiler if the 
project's minimum deployment target is lower than the introductory version of 
the symbol.

> > You are right about the deprecated warning not being emitted in the
> > example
> > above, currently not sure why, but I still think
> > MAC_OS_X_VERSION_MAX_ALLOWED is the way to go in this case.
> 
> The page and the header file I referred the above would help
> understanding the behavior.

Yeah, I already checked that. It basically translates to:

__attribute__((availability(macosx,introduced=10.0,deprecated=12.0)))

So next I would need to read clang sources how this attribute is implemented 
exactly. Not today. ;-)

Best regards,
Christian Schoenebeck

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Akihiko Odaki]

On 2022/01/11 6:05, Christian Schoenebeck wrote:
> On Montag, 10. Januar 2022 21:39:28 CET Akihiko Odaki wrote:
>> On 2022/01/11 5:22, Christian Schoenebeck wrote:
>>> On Montag, 10. Januar 2022 20:01:40 CET Akihiko Odaki wrote:
>>>> On 2022/01/11 3:46, Christian Schoenebeck wrote:
>>>>> On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
>>>>>> On 2022/01/10 22:22, Peter Maydell wrote:
>>>>>>> On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
>>>>>>>
>>>>>>> <qemu_oss@crudebyte.com> wrote:
>>>>>>>> I'd suggest to use:
>>>>>>>>
>>>>>>>> #if !defined(MAC_OS_VERSION_12_0) ||
>>>>>>>>
>>>>>>>>         (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
>>>>>>>>
>>>>>>>> #define kAudioObjectPropertyElementMain
>>>>>>>> kAudioObjectPropertyElementMaster
>>>>>>>> #endif
>>>>>>>
>>>>>>> This is also how we do this for existing checks of this sort,
>>>>>>> like the one in osdep.h for qemu_thread_jit_execute().
>>>>>>>
>>>>>>> -- PMM
>>>>>>
>>>>>> If I understand correctly, Many macOS-specific codes already no longer
>>>>>> complies with GCC because they depend on modern features GCC doesn't
>>>>>> provide. The most problematic construction is block; it is extensively
>>>>>> used by Apple's ABI and API and you cannot avoid using it even if you
>>>>>> try.
>>>>>
>>>>> You mean Obj-C blocks? That's working with GCC for decades. I am not
>>>>> aware
>>>>> about any recent changes to Obj-C block mechanisms by Apple.
>>>>>
>>>>>> Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of
>>>>>> the supported version. The lower bound should be preferred here because
>>>>>> the usage of the new identifier is applied regardless of the version of
>>>>>> the host system. It is in contrary to the usage of
>>>>>> MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
>>>>>> used only for the newer versions. The lower bound is defined as
>>>>>> MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of
>>>>>> the
>>>>>> two macros because they have the same value in QEMU and
>>>>>> kAudioObjectPropertyElementMain is a constant resolved compile-time,
>>>>>> but
>>>>>> it is still nice to have the code semantically correct.
>>>>>
>>>>> For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the
>>>>> correct
>>>>> one. This is about whether enum kAudioObjectPropertyElementMain is
>>>>> defined in the SDK header files. That's all. And the new enum
>>>>> kAudioObjectPropertyElementMain is pure refactoring of the enum's old
>>>>> name due to social reasons ("Master"). The actual reflected numeric
>>>>> value
>>>>> and semantic of the enum is unchanged and the resulting binary and
>>>>> behaviour are identical.
>>>>
>>>> There are a few problems with the usage of MAC_OS_X_VERSION_MAX_ALLOWED:
>>>> - The deprecation warning is designed to work with
>>>> MAC_OS_X_VERSION_MIN_REQUIRED. You may verify that with:
>>>> cc -mmacosx-version-min=12.0 -x c - <<EOF
>>>> #include <CoreAudio/CoreAudio.h>
>>>>
>>>> int main()
>>>> {
>>>>
>>>>       int k = kAudioObjectPropertyElementMaster;
>>>>
>>>> }
>>>> EOF
>>>
>>> That's actually interesting. On other projects I definitely saw deprecated
>>> warnings before on API declarations that were deprecated at a version
>>> higher than the project's minimum deployment target.
>>>
>>> Did they change that?
>>
>> I don't think so. The behavior is documented at:
>> https://clang.llvm.org/docs/AttributeReference.html#availability
>> and the example refers to OS X 10.4, 10.6, 10.7. Probably they haven't
>> changed the behavior for decades.
> 
> The descriptions is very vague. It sais e.g. "If Clang is instructed to
> compile code for macOS 10.6 ...". So it is describing it only via singular
> version per example. We are talking about version ranges however.
> 
>> MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/os/availabilit
>> y.h says manually defining API_TO_BE_DEPRECATED can alter the behavior so
>> that may be the case.
>>
>>>> - The programmer must be aware whether it is constant or not.
>>>> - The macro tells about the runtime and not the SDK. There is no way to
>>>> tell the SDK version and that is why I suggested __is_identifier at the
>>>> first place. However, now I'm convinced that
>>>> MAC_OS_X_VERSION_MIN_REQUIRED is the better option because of the above
>>>> reasons.
>>>
>>> If you make it dependent on MAC_OS_X_VERSION_MIN_REQUIRED, people with
>>> older SDKs (e.g. Xcode <=13.0) would get a compiler error.
>>
>> __is_identifier is the only option if you need a compatibility with the
>> older SDKs while specifying a greater version for
>> MAC_OS_X_VERSION_MIN_REQUIRED. It also applies to
>> MAC_OS_X_VERSION_MAX_ALLOWED; they give the possible runtime versions
>> and not the SDK version.
> 
> I have never used __is_identifier() for such things. I always used
> MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED and it was
> always doing the job.
> 
> And for symbols: those are automatically weak linked by the compiler if the
> project's minimum deployment target is lower than the introductory version of
> the symbol.

That would not happen with older SDKs because they don't know even 
whether the identifier is a symbol. That is usually not a problem though 
because such a problem happens only when the version range specified 
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED are not 
supported by the SDK.

> 
>>> You are right about the deprecated warning not being emitted in the
>>> example
>>> above, currently not sure why, but I still think
>>> MAC_OS_X_VERSION_MAX_ALLOWED is the way to go in this case.
>>
>> The page and the header file I referred the above would help
>> understanding the behavior.
> 
> Yeah, I already checked that. It basically translates to:
> 
> __attribute__((availability(macosx,introduced=10.0,deprecated=12.0)))
> 
> So next I would need to read clang sources how this attribute is implemented
> exactly. Not today. ;-)
> 
> Best regards,
> Christian Schoenebeck
> 
> 

It is because the compiler only checks the minimum. The upper bound is a 
purely library-defined construct.

MacOSX.sdk/usr/include/Availability.h says:
 > The min OS version is specified as an option to the compiler:
 > -mmacosx-version-min=10.x when building for Mac OS X, and 
-miphoneos-version-min=y.z
 > when building for the iPhone.  The upper bound for the OS version is 
rarely needed,
 > but it can be set on the command line via: 
-D__MAC_OS_X_VERSION_MAX_ALLOWED=10x0 for
 > Mac OS X and __IPHONE_OS_VERSION_MAX_ALLOWED = y0z00 for iOS.

As you can see here, the maximum is just a macro, unlike the minimum.

Regards,
Akihiko Odaki

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Christian Schoenebeck]

On Montag, 10. Januar 2022 22:05:43 CET Christian Schoenebeck wrote:
> On Montag, 10. Januar 2022 21:39:28 CET Akihiko Odaki wrote:
> > On 2022/01/11 5:22, Christian Schoenebeck wrote:
> > > On Montag, 10. Januar 2022 20:01:40 CET Akihiko Odaki wrote:
> > >> On 2022/01/11 3:46, Christian Schoenebeck wrote:
> > >>> On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
> > >>>> On 2022/01/10 22:22, Peter Maydell wrote:
> > >>>>> On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
> > >>>>> 
> > >>>>> <qemu_oss@crudebyte.com> wrote:
> > >>>> Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound
> > >>>> of
> > >>>> the supported version. The lower bound should be preferred here
> > >>>> because
> > >>>> the usage of the new identifier is applied regardless of the version
> > >>>> of
> > >>>> the host system. It is in contrary to the usage of
> > >>>> MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
> > >>>> used only for the newer versions. The lower bound is defined as
> > >>>> MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of
> > >>>> the
> > >>>> two macros because they have the same value in QEMU and
> > >>>> kAudioObjectPropertyElementMain is a constant resolved compile-time,
> > >>>> but
> > >>>> it is still nice to have the code semantically correct.
> > >>> 
> > >>> For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the
> > >>> correct
> > >>> one. This is about whether enum kAudioObjectPropertyElementMain is
> > >>> defined in the SDK header files. That's all. And the new enum
> > >>> kAudioObjectPropertyElementMain is pure refactoring of the enum's old
> > >>> name due to social reasons ("Master"). The actual reflected numeric
> > >>> value
> > >>> and semantic of the enum is unchanged and the resulting binary and
> > >>> behaviour are identical.
> > >> 
> > >> There are a few problems with the usage of
> > >> MAC_OS_X_VERSION_MAX_ALLOWED:
> > >> - The deprecation warning is designed to work with
> > >> MAC_OS_X_VERSION_MIN_REQUIRED. You may verify that with:
> > >> cc -mmacosx-version-min=12.0 -x c - <<EOF
> > >> #include <CoreAudio/CoreAudio.h>
> > >> 
> > >> int main()
> > >> {
> > >> 
> > >>      int k = kAudioObjectPropertyElementMaster;
> > >> 
> > >> }
> > >> EOF
> > > 
> > > That's actually interesting. On other projects I definitely saw
> > > deprecated
> > > warnings before on API declarations that were deprecated at a version
> > > higher than the project's minimum deployment target.
> > > 
> > > Did they change that?
> > 
> > I don't think so. The behavior is documented at:
> > https://clang.llvm.org/docs/AttributeReference.html#availability
> > and the example refers to OS X 10.4, 10.6, 10.7. Probably they haven't
> > changed the behavior for decades.
> 
> The descriptions is very vague. It sais e.g. "If Clang is instructed to
> compile code for macOS 10.6 ...". So it is describing it only via singular
> version per example. We are talking about version ranges however.
> 
> > MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/os/availabil
> > it y.h says manually defining API_TO_BE_DEPRECATED can alter the behavior
> > so that may be the case.
> > 
> > >> - The programmer must be aware whether it is constant or not.
> > >> - The macro tells about the runtime and not the SDK. There is no way to
> > >> tell the SDK version and that is why I suggested __is_identifier at the
> > >> first place. However, now I'm convinced that
> > >> MAC_OS_X_VERSION_MIN_REQUIRED is the better option because of the above
> > >> reasons.
> > > 
> > > If you make it dependent on MAC_OS_X_VERSION_MIN_REQUIRED, people with
> > > older SDKs (e.g. Xcode <=13.0) would get a compiler error.
> > 
> > __is_identifier is the only option if you need a compatibility with the
> > older SDKs while specifying a greater version for
> > MAC_OS_X_VERSION_MIN_REQUIRED. It also applies to
> > MAC_OS_X_VERSION_MAX_ALLOWED; they give the possible runtime versions
> > and not the SDK version.
> 
> I have never used __is_identifier() for such things. I always used
> MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED and it was
> always doing the job.
> 
> And for symbols: those are automatically weak linked by the compiler if the
> project's minimum deployment target is lower than the introductory version
> of the symbol.
> 
> > > You are right about the deprecated warning not being emitted in the
> > > example
> > > above, currently not sure why, but I still think
> > > MAC_OS_X_VERSION_MAX_ALLOWED is the way to go in this case.
> > 
> > The page and the header file I referred the above would help
> > understanding the behavior.
> 
> Yeah, I already checked that. It basically translates to:
> 
> __attribute__((availability(macosx,introduced=10.0,deprecated=12.0)))
> 
> So next I would need to read clang sources how this attribute is implemented
> exactly. Not today. ;-)

Curiousity was stronger: the original clang behaviour was as I explained:
https://github.com/llvm-mirror/clang/commit/0a0d2b179085a52c10402feebeb6db8b4d96a140#diff-97c4322e86bf436b7f79f4fcafc4b7beb092da08c5c23f294f98b5bb0a7f9a31

Quote:

"
For example,

  void foo()
  __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));

...

   - If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
    will result in a deprecation warning, as if we had placed
    attribute((deprecated)) on it ...
"

Relevant code section (in that original commit):

static AvailabilityResult CheckAvailability(ASTContext &Context,
                                            const AvailabilityAttr *A,
                                            std::string *Message) {
  ...
  VersionTuple TargetMinVersion = Context.Target.getPlatformMinVersion();
  ...
  // Make sure that this declaration hasn't been deprecated.
  if (!A->getDeprecated().empty() && TargetMinVersion >= A->getDeprecated()) {
    if (Message) {
      Message->clear();
      llvm::raw_string_ostream Out(*Message);
      Out << "first deprecated in " << PrettyPlatformName << ' '
          << A->getDeprecated();
    }

    return AR_Deprecated;
  }
  ...
}

Still no idea why it behaves differently now. There were some changes in LLVM
on this, but they seem to deal with other things like partial availability
i.e. for weak linking:
https://github.com/llvm/llvm-project/commit/48c7cc9bc04f595b7b335aeae83df4c0221b6d13

Best regards,
Christian Schoenebeck

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12

[Christian Schoenebeck]

On Dienstag, 11. Januar 2022 13:35:05 CET Christian Schoenebeck wrote:
> Curiousity was stronger: the original clang behaviour was as I explained:
> https://github.com/llvm-mirror/clang/commit/0a0d2b179085a52c10402feebeb6db8b
> 4d96a140#diff-97c4322e86bf436b7f79f4fcafc4b7beb092da08c5c23f294f98b5bb0a7f9a
> 31
> 
> Quote:
> 
> "
> For example,
> 
>   void foo()
>  
> __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsolete
> d=10.6)));
> 
> ...
> 
>    - If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
>     will result in a deprecation warning, as if we had placed
>     attribute((deprecated)) on it ...
> "
> 
> Relevant code section (in that original commit):
> 
> static AvailabilityResult CheckAvailability(ASTContext &Context,
>                                             const AvailabilityAttr *A,
>                                             std::string *Message) {
>   ...
>   VersionTuple TargetMinVersion = Context.Target.getPlatformMinVersion();
>   ...
>   // Make sure that this declaration hasn't been deprecated.
>   if (!A->getDeprecated().empty() && TargetMinVersion >= A->getDeprecated())

Stupid me, you are right. No deprecated warning unless minimum deployment 
target is >= the attribute's deprecated version.

So it was always like this. My bad. :)

> { if (Message) {
>       Message->clear();
>       llvm::raw_string_ostream Out(*Message);
>       Out << "first deprecated in " << PrettyPlatformName << ' '
>           << A->getDeprecated();
>     }
> 
>     return AR_Deprecated;
>   }
>   ...
> }

Best regards,
Christian Schoenebeck

[RFC PATCH v2 3/6] block/file-posix: Remove a deprecation warning on macOS 12

[Philippe Mathieu-Daudé]

When building on macOS 12 we get:

  block/file-posix.c:3335:18: warning: 'IOMasterPort' is deprecated: first deprecated in macOS 12.0 [-Wdeprecated-declarations]
      kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
                   ^~~~~~~~~~~~
                   IOMainPort

Use IOMainPort (define it to IOMasterPort on macOS < 12),
and replace 'master' by 'main' in a variable name.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 block/file-posix.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index b283093e5b7..0dcfce18560 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -3324,17 +3324,22 @@ BlockDriver bdrv_file = {
 #if defined(__APPLE__) && defined(__MACH__)
 static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
                                 CFIndex maxPathSize, int flags);
+
+#if !defined(MAC_OS_VERSION_12_0)
+#define IOMainPort IOMasterPort
+#endif
+
 static char *FindEjectableOpticalMedia(io_iterator_t *mediaIterator)
 {
     kern_return_t kernResult = KERN_FAILURE;
-    mach_port_t     masterPort;
+    mach_port_t mainPort;
     CFMutableDictionaryRef  classesToMatch;
     const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
     char *mediaType = NULL;
 
-    kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
+    kernResult = IOMainPort(MACH_PORT_NULL, &mainPort);
     if ( KERN_SUCCESS != kernResult ) {
-        printf( "IOMasterPort returned %d\n", kernResult );
+        printf("IOMainPort returned %d\n", kernResult);
     }
 
     int index;
@@ -3347,7 +3352,7 @@ static char *FindEjectableOpticalMedia(io_iterator_t *mediaIterator)
         }
         CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
                              kCFBooleanTrue);
-        kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
+        kernResult = IOServiceGetMatchingServices(mainPort, classesToMatch,
                                                   mediaIterator);
         if (kernResult != KERN_SUCCESS) {
             error_report("Note: IOServiceGetMatchingServices returned %d",
-- 
2.33.1

[RFC PATCH v2 4/6] hvf: Make hvf_get_segments() / hvf_put_segments() local

[Philippe Mathieu-Daudé]

Both hvf_get_segments/hvf_put_segments() functions are only
used within x86hvf.c: do not declare them as public API.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/i386/hvf/x86hvf.h | 2 --
 target/i386/hvf/x86hvf.c | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/target/i386/hvf/x86hvf.h b/target/i386/hvf/x86hvf.h
index 99ed8d608dd..db6003d6bda 100644
--- a/target/i386/hvf/x86hvf.h
+++ b/target/i386/hvf/x86hvf.h
@@ -26,11 +26,9 @@ void hvf_set_segment(struct CPUState *cpu, struct vmx_segment *vmx_seg,
                      SegmentCache *qseg, bool is_tr);
 void hvf_get_segment(SegmentCache *qseg, struct vmx_segment *vmx_seg);
 void hvf_put_xsave(CPUState *cpu_state);
-void hvf_put_segments(CPUState *cpu_state);
 void hvf_put_msrs(CPUState *cpu_state);
 void hvf_get_xsave(CPUState *cpu_state);
 void hvf_get_msrs(CPUState *cpu_state);
 void vmx_clear_int_window_exiting(CPUState *cpu);
-void hvf_get_segments(CPUState *cpu_state);
 void vmx_update_tpr(CPUState *cpu);
 #endif
diff --git a/target/i386/hvf/x86hvf.c b/target/i386/hvf/x86hvf.c
index 05ec1bddc4e..907f09f1b43 100644
--- a/target/i386/hvf/x86hvf.c
+++ b/target/i386/hvf/x86hvf.c
@@ -83,7 +83,7 @@ void hvf_put_xsave(CPUState *cpu_state)
     }
 }
 
-void hvf_put_segments(CPUState *cpu_state)
+static void hvf_put_segments(CPUState *cpu_state)
 {
     CPUX86State *env = &X86_CPU(cpu_state)->env;
     struct vmx_segment seg;
@@ -166,7 +166,7 @@ void hvf_get_xsave(CPUState *cpu_state)
     x86_cpu_xrstor_all_areas(X86_CPU(cpu_state), xsave, xsave_len);
 }
 
-void hvf_get_segments(CPUState *cpu_state)
+static void hvf_get_segments(CPUState *cpu_state)
 {
     CPUX86State *env = &X86_CPU(cpu_state)->env;
 
-- 
2.33.1

[RFC PATCH v2 5/6] hvf: Remove deprecated hv_vcpu_flush() calls

[Philippe Mathieu-Daudé]

When building on macOS 12, we get:

  In file included from ../target/i386/hvf/hvf.c:59:
  ../target/i386/hvf/vmx.h:174:5: error: 'hv_vcpu_flush' is deprecated: first deprecated in macOS 11.0 - This API has no effect and always returns HV_UNSUPPORTED [-Werror,-Wdeprecated-declarations]
      hv_vcpu_flush(vcpu);
      ^
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Hypervisor.framework/Headers/hv.h:364:20: note: 'hv_vcpu_flush' has been explicitly marked deprecated here
  extern hv_return_t hv_vcpu_flush(hv_vcpuid_t vcpu)
                     ^

Since this call "has no effect", simply remove it ¯\_(ツ)_/¯

Not very useful deprecation doc:
https://developer.apple.com/documentation/hypervisor/1441386-hv_vcpu_flush

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/i386/hvf/vmx.h      | 2 --
 target/i386/hvf/x86_task.c | 1 -
 target/i386/hvf/x86hvf.c   | 2 --
 3 files changed, 5 deletions(-)

diff --git a/target/i386/hvf/vmx.h b/target/i386/hvf/vmx.h
index 6df87116f62..094fb9b9dc9 100644
--- a/target/i386/hvf/vmx.h
+++ b/target/i386/hvf/vmx.h
@@ -159,7 +159,6 @@ static inline void macvm_set_cr0(hv_vcpuid_t vcpu, uint64_t cr0)
     wvmcs(vcpu, VMCS_GUEST_CR0, cr0 | CR0_NE | CR0_ET);
 
     hv_vcpu_invalidate_tlb(vcpu);
-    hv_vcpu_flush(vcpu);
 }
 
 static inline void macvm_set_cr4(hv_vcpuid_t vcpu, uint64_t cr4)
@@ -171,7 +170,6 @@ static inline void macvm_set_cr4(hv_vcpuid_t vcpu, uint64_t cr4)
     wvmcs(vcpu, VMCS_CR4_MASK, CR4_VMXE);
 
     hv_vcpu_invalidate_tlb(vcpu);
-    hv_vcpu_flush(vcpu);
 }
 
 static inline void macvm_set_rip(CPUState *cpu, uint64_t rip)
diff --git a/target/i386/hvf/x86_task.c b/target/i386/hvf/x86_task.c
index 422156128b7..c8dc3d48fa8 100644
--- a/target/i386/hvf/x86_task.c
+++ b/target/i386/hvf/x86_task.c
@@ -181,5 +181,4 @@ void vmx_handle_task_switch(CPUState *cpu, x68_segment_selector tss_sel, int rea
     store_regs(cpu);
 
     hv_vcpu_invalidate_tlb(cpu->hvf->fd);
-    hv_vcpu_flush(cpu->hvf->fd);
 }
diff --git a/target/i386/hvf/x86hvf.c b/target/i386/hvf/x86hvf.c
index 907f09f1b43..bec9fc58146 100644
--- a/target/i386/hvf/x86hvf.c
+++ b/target/i386/hvf/x86hvf.c
@@ -125,8 +125,6 @@ static void hvf_put_segments(CPUState *cpu_state)
 
     hvf_set_segment(cpu_state, &seg, &env->ldt, false);
     vmx_write_segment_descriptor(cpu_state, &seg, R_LDTR);
-    
-    hv_vcpu_flush(cpu_state->hvf->fd);
 }
     
 void hvf_put_msrs(CPUState *cpu_state)
-- 
2.33.1

[PATCH v2 6/6] gitlab-ci: Support macOS 12 via cirrus-run

[Philippe Mathieu-Daudé]

Add support for macOS 12 build on Cirrus-CI, similarly to commit
0e103a65ba1 ("gitlab: support for ... macOS 11 via cirrus-run").

Disable deprecation warnings on Objective C to avoid:

  [2789/6622] Compiling Objective-C object libcommon.fa.p/ui_cocoa.m.o
  ui/cocoa.m:1411:16: error: 'setAllowedFileTypes:' is deprecated: first deprecated in macOS 12.0 - Use -allowedContentTypes instead [-Werror,-Wdeprecated-declarations]
      [openPanel setAllowedFileTypes: supportedImageFileTypes];
                 ^
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: property 'allowedFileTypes' is declared deprecated here
  @property (nullable, copy) NSArray<NSString *> *allowedFileTypes API_DEPRECATED("Use -allowedContentTypes instead", macos(10.3,12.0));
                                                  ^
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: 'setAllowedFileTypes:' has been explicitly marked deprecated here
  FAILED: libcommon.fa.p/ui_cocoa.m.o

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
Generated using lcitool from:
https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/210
---
 .gitlab-ci.d/cirrus.yml           | 16 ++++++++++++++++
 .gitlab-ci.d/cirrus/macos-12.vars | 16 ++++++++++++++++
 2 files changed, 32 insertions(+)
 create mode 100644 .gitlab-ci.d/cirrus/macos-12.vars

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 19e6c21401b..719008b13ca 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -90,6 +90,22 @@ x64-macos-11-base-build:
     PKG_CONFIG_PATH: /usr/local/opt/curl/lib/pkgconfig:/usr/local/opt/ncurses/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig
     TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat check-qtest-x86_64
 
+x64-macos-12-base-build:
+  extends: .cirrus_build_job
+  variables:
+    NAME: macos-12
+    CIRRUS_VM_INSTANCE_TYPE: osx_instance
+    CIRRUS_VM_IMAGE_SELECTOR: image
+    CIRRUS_VM_IMAGE_NAME: monterey-base
+    CIRRUS_VM_CPUS: 12
+    CIRRUS_VM_RAM: 24G
+    UPDATE_COMMAND: brew update
+    INSTALL_COMMAND: brew install
+    PATH_EXTRA: /usr/local/opt/ccache/libexec:/usr/local/opt/gettext/bin
+    PKG_CONFIG_PATH: /usr/local/opt/curl/lib/pkgconfig:/usr/local/opt/ncurses/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig
+    TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat check-qtest-x86_64
+    CONFIGURE_ARGS: --extra-objcflags=-Wno-deprecated-declarations
+
 
 # The following jobs run VM-based tests via KVM on a Linux-based Cirrus-CI job
 .cirrus_kvm_job:
diff --git a/.gitlab-ci.d/cirrus/macos-12.vars b/.gitlab-ci.d/cirrus/macos-12.vars
new file mode 100644
index 00000000000..997dbc762c8
--- /dev/null
+++ b/.gitlab-ci.d/cirrus/macos-12.vars
@@ -0,0 +1,16 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool variables macos-12 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
+CCACHE='/usr/local/bin/ccache'
+CPAN_PKGS='Test::Harness'
+CROSS_PKGS=''
+MAKE='/usr/local/bin/gmake'
+NINJA='/usr/local/bin/ninja'
+PACKAGING_COMMAND='brew'
+PIP3='/usr/local/bin/pip3'
+PKGS='bash bc bzip2 capstone ccache cpanminus ctags curl dbus diffutils dtc gcovr gettext git glib gnu-sed gnutls gtk+3 jemalloc jpeg-turbo libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp libssh libtasn1 libusb libxml2 llvm lzo make meson ncurses nettle ninja perl pixman pkg-config python3 rpm2cpio sdl2 sdl2_image snappy sparse spice-protocol tesseract texinfo usbredir vde vte3 zlib zstd'
+PYPI_PKGS='PyYAML numpy pillow sphinx sphinx-rtd-theme virtualenv'
+PYTHON='/usr/local/bin/python3'
-- 
2.33.1

Re: [PATCH v2 6/6] gitlab-ci: Support macOS 12 via cirrus-run

[Akihiko Odaki]

On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
> Add support for macOS 12 build on Cirrus-CI, similarly to commit
> 0e103a65ba1 ("gitlab: support for ... macOS 11 via cirrus-run").
> 
> Disable deprecation warnings on Objective C to avoid:
> 
>    [2789/6622] Compiling Objective-C object libcommon.fa.p/ui_cocoa.m.o
>    ui/cocoa.m:1411:16: error: 'setAllowedFileTypes:' is deprecated: first deprecated in macOS 12.0 - Use -allowedContentTypes instead [-Werror,-Wdeprecated-declarations]
>        [openPanel setAllowedFileTypes: supportedImageFileTypes];
>                   ^
>    /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: property 'allowedFileTypes' is declared deprecated here
>    @property (nullable, copy) NSArray<NSString *> *allowedFileTypes API_DEPRECATED("Use -allowedContentTypes instead", macos(10.3,12.0));
>                                                    ^
>    /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: 'setAllowedFileTypes:' has been explicitly marked deprecated here
>    FAILED: libcommon.fa.p/ui_cocoa.m.o
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Globally disabling deprecation warnings sounds bad. I came up with a few 
alternatives:
- Just remove the call of [NSSavePanel allowedFileTypes:]. Actually I 
think it is harming the usability rather than improving it. An image 
file, which is being chosen by the panel, can be a raw file and have a 
variety of file extensions and many are not covered by the provided list 
(e.g. "udf"). Other platforms like GTK can provide an option to open a 
file with an extension not listed, but Cocoa can't. It forces the user 
to rename the file to give an extension in the list. Moreover, Cocoa 
does not tell which extensions are in the list so the user needs to read 
the source code, which is pretty bad.

- Use a different method to provide the same functionality.

- To locally disable the warning, enclose the statement with:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
and
#pragma clang diagnostic pop

Regards,
Akihiko Odaki

> ---
> Generated using lcitool from:
> https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/210
> ---
>   .gitlab-ci.d/cirrus.yml           | 16 ++++++++++++++++
>   .gitlab-ci.d/cirrus/macos-12.vars | 16 ++++++++++++++++
>   2 files changed, 32 insertions(+)
>   create mode 100644 .gitlab-ci.d/cirrus/macos-12.vars
> 
> diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
> index 19e6c21401b..719008b13ca 100644
> --- a/.gitlab-ci.d/cirrus.yml
> +++ b/.gitlab-ci.d/cirrus.yml
> @@ -90,6 +90,22 @@ x64-macos-11-base-build:
>       PKG_CONFIG_PATH: /usr/local/opt/curl/lib/pkgconfig:/usr/local/opt/ncurses/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig
>       TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat check-qtest-x86_64
>   
> +x64-macos-12-base-build:
> +  extends: .cirrus_build_job
> +  variables:
> +    NAME: macos-12
> +    CIRRUS_VM_INSTANCE_TYPE: osx_instance
> +    CIRRUS_VM_IMAGE_SELECTOR: image
> +    CIRRUS_VM_IMAGE_NAME: monterey-base
> +    CIRRUS_VM_CPUS: 12
> +    CIRRUS_VM_RAM: 24G
> +    UPDATE_COMMAND: brew update
> +    INSTALL_COMMAND: brew install
> +    PATH_EXTRA: /usr/local/opt/ccache/libexec:/usr/local/opt/gettext/bin
> +    PKG_CONFIG_PATH: /usr/local/opt/curl/lib/pkgconfig:/usr/local/opt/ncurses/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig
> +    TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat check-qtest-x86_64
> +    CONFIGURE_ARGS: --extra-objcflags=-Wno-deprecated-declarations
> +
>   
>   # The following jobs run VM-based tests via KVM on a Linux-based Cirrus-CI job
>   .cirrus_kvm_job:
> diff --git a/.gitlab-ci.d/cirrus/macos-12.vars b/.gitlab-ci.d/cirrus/macos-12.vars
> new file mode 100644
> index 00000000000..997dbc762c8
> --- /dev/null
> +++ b/.gitlab-ci.d/cirrus/macos-12.vars
> @@ -0,0 +1,16 @@
> +# THIS FILE WAS AUTO-GENERATED
> +#
> +#  $ lcitool variables macos-12 qemu
> +#
> +# https://gitlab.com/libvirt/libvirt-ci
> +
> +CCACHE='/usr/local/bin/ccache'
> +CPAN_PKGS='Test::Harness'
> +CROSS_PKGS=''
> +MAKE='/usr/local/bin/gmake'
> +NINJA='/usr/local/bin/ninja'
> +PACKAGING_COMMAND='brew'
> +PIP3='/usr/local/bin/pip3'
> +PKGS='bash bc bzip2 capstone ccache cpanminus ctags curl dbus diffutils dtc gcovr gettext git glib gnu-sed gnutls gtk+3 jemalloc jpeg-turbo libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp libssh libtasn1 libusb libxml2 llvm lzo make meson ncurses nettle ninja perl pixman pkg-config python3 rpm2cpio sdl2 sdl2_image snappy sparse spice-protocol tesseract texinfo usbredir vde vte3 zlib zstd'
> +PYPI_PKGS='PyYAML numpy pillow sphinx sphinx-rtd-theme virtualenv'
> +PYTHON='/usr/local/bin/python3'

Re: [PATCH v2 6/6] gitlab-ci: Support macOS 12 via cirrus-run

[Daniel P. Berrangé]

On Sun, Jan 09, 2022 at 06:06:12PM +0100, Philippe Mathieu-Daudé wrote:
> Add support for macOS 12 build on Cirrus-CI, similarly to commit
> 0e103a65ba1 ("gitlab: support for ... macOS 11 via cirrus-run").
> 
> Disable deprecation warnings on Objective C to avoid:
> 
>   [2789/6622] Compiling Objective-C object libcommon.fa.p/ui_cocoa.m.o
>   ui/cocoa.m:1411:16: error: 'setAllowedFileTypes:' is deprecated: first deprecated in macOS 12.0 - Use -allowedContentTypes instead [-Werror,-Wdeprecated-declarations]
>       [openPanel setAllowedFileTypes: supportedImageFileTypes];
>                  ^
>   /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: property 'allowedFileTypes' is declared deprecated here
>   @property (nullable, copy) NSArray<NSString *> *allowedFileTypes API_DEPRECATED("Use -allowedContentTypes instead", macos(10.3,12.0));
>                                                   ^
>   /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: 'setAllowedFileTypes:' has been explicitly marked deprecated here
>   FAILED: libcommon.fa.p/ui_cocoa.m.o
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Generated using lcitool from:
> https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/210
> ---
>  .gitlab-ci.d/cirrus.yml           | 16 ++++++++++++++++
>  .gitlab-ci.d/cirrus/macos-12.vars | 16 ++++++++++++++++
>  2 files changed, 32 insertions(+)
>  create mode 100644 .gitlab-ci.d/cirrus/macos-12.vars

There's going to be a minor interaction with my patches that integrate
lcitool more formally in QEMU. Alex has them queued here:

  https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg00558.html

could you rebase on top of that series - all it will really mean
in this case is including the git submodule update on top, and
updating the refresh script to include macos-12 too

 https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg00571.html

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|