qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
To: "Thomas Huth" <thuth@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Martin Storsjö" <martin@martin.st>
Cc: qemu-devel@nongnu.org, "Cleber Rosa" <crosa@redhat.com>,
	"John Snow" <jsnow@redhat.com>,
	"Michael Roth" <michael.roth@amd.com>,
	"Alexandre Iooss" <erdnaxe@crans.org>,
	"Konstantin Kostiuk" <kkostiuk@redhat.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Mahmoud Mandour" <ma.mandourr@gmail.com>
Subject: Re: [PATCH 07/12] win32: use compiler option instead of attribute gcc_struct
Date: Thu, 31 Oct 2024 12:01:12 -0700	[thread overview]
Message-ID: <2831cc99-b2c3-414f-9a81-0e39e8dc6d34@linaro.org> (raw)
In-Reply-To: <e7e2f194-601c-4c26-bc51-1fc786f06aa2@redhat.com>

On 10/31/24 03:44, Thomas Huth wrote:
> On 31/10/2024 10.28, Daniel P. Berrangé wrote:
>> On Wed, Oct 30, 2024 at 09:04:21PM -0700, Pierrick Bouvier wrote:
>>> This attribute is not recognized by clang, but the associated option is.
>>>
>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>>> ---
>>>    meson.build                               | 8 ++++----
>>>    include/qemu/compiler.h                   | 7 +------
>>>    subprojects/libvhost-user/libvhost-user.h | 6 +-----
>>>    3 files changed, 6 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/meson.build b/meson.build
>>> index d8af08299e0..d0d5dbe1479 100644
>>> --- a/meson.build
>>> +++ b/meson.build
>>> @@ -330,10 +330,10 @@ elif host_os == 'sunos'
>>>    elif host_os == 'haiku'
>>>      qemu_common_flags += ['-DB_USE_POSITIVE_POSIX_ERRORS', '-D_BSD_SOURCE', '-fPIC']
>>>    elif host_os == 'windows'
>>> -  if not compiler.compiles('struct x { int y; } __attribute__((gcc_struct));',
>>> -                           args: '-Werror')
>>> -    error('Your compiler does not support __attribute__((gcc_struct)) - please use GCC instead of Clang')
>>> -  endif
>>> +  # https://gcc.gnu.org/onlinedocs/gcc/x86-Type-Attributes.html
>>> +  # We use this compilation option instead of relying on gcc_struct attribute
>>> +  # because clang does not support it (but supports the option).
>>> +  qemu_common_flags += ['-mno-ms-bitfields']
>>>    endif
>>
>> Is this really safe for us to use ?   The current gcc_struct
>> attribute affects only structs marked as QEMU_PACKED. This
>> flag will affect all code.
>>
>> If we call from QEMU code into Windows native APIs, and pass
>> or receive structs, then those structs' layouts would be
>> affected by this flag. I don't have a specific example, but
>> this feels unsafe to me, otherwise we would have done this
>> originally rather than only targetting internal packed structs
>> with the gcc_struct attribute.
> 
> I agree with Daniel, we likely cannot use this switch globally.
> 
> But seems like Clang folks are trying to include support for the attribute,
> see: https://gitlab.com/qemu-project/qemu/-/issues/2476#note_2159643081
> so I'd rather recommend to wait for that for proper Clang support here.
> 
>    Thomas
> 

Thanks for your reviews.
(adding Martin to the conversation, who worked on llvm-mingw toolchain, 
and commented on GitLab issue).

As mentioned in gcc documentation, this option applies only to packed 
structures, or when bitfield are used. So this is this second case that 
may be a problem for us indeed.
Looking at mingw windows headers, I could find a few of them, but I 
didn't check if they were used directly or indirectly by our code.

After reading the gitlab issue attached, and links associated, it seems 
that QEMU is one of the only big projects using this. And clang support 
is only blocked by this.
The upstream llvm support for this might take more time than expected 
(the PR was opened more than 1 year ago... and the original report for 
missing attribute support was in 2015), so I'm not very confident this 
will appear "soon".

I noticed that Daniel conducted a small investigation using pahole, and 
the report was that there were not so many difference (one found, but 
only compile x86_64-softmmu target).

I would be willing to perform a full build (all dependencies, and all 
targets), and compare what we obtain.
If we can fix the corner cases, would you be open to accept removing 
gcc_struct from the codebase?
I can understand if it's a big NO, but I think it's unfortunate that we 
are blocked today just because of this.

  reply	other threads:[~2024-10-31 19:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-31  4:04 [PATCH 00/12] Enable building plugins on Windows with Clang Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 01/12] scripts: remove erroneous file that breaks git clone on Windows Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 02/12] contrib/plugins/cflow: fix warning Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 03/12] meson: build contrib/plugins with meson Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 04/12] contrib/plugins: remove Makefile for contrib/plugins Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 05/12] qga: fix -Wsometimes-uninitialized windows warning Pierrick Bouvier
2024-10-31 13:32   ` Konstantin Kostiuk
2024-11-04 13:43     ` Konstantin Kostiuk
2024-10-31  4:04 ` [PATCH 06/12] qga: fix missing static and prototypes windows warnings Pierrick Bouvier
2024-10-31  4:11   ` Philippe Mathieu-Daudé
2024-10-31 13:32   ` Konstantin Kostiuk
2024-11-04 13:43     ` Konstantin Kostiuk
2024-11-04 22:30       ` Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 07/12] win32: use compiler option instead of attribute gcc_struct Pierrick Bouvier
2024-10-31  9:28   ` Daniel P. Berrangé
2024-10-31 10:44     ` Thomas Huth
2024-10-31 19:01       ` Pierrick Bouvier [this message]
2024-10-31  4:04 ` [PATCH 08/12] plugins: enable linking with clang/lld Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 09/12] plugins: add missing export for qemu_plugin_num_vcpus Pierrick Bouvier
2024-10-31  4:14   ` Philippe Mathieu-Daudé
2024-10-31  4:04 ` [PATCH 10/12] plugins: detect qemu plugin API symbols from header Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 11/12] plugins: eradicate qemu-plugins.symbols static file Pierrick Bouvier
2024-10-31  4:04 ` [PATCH 12/12] docs: add information on how to setup build environments Pierrick Bouvier
2024-10-31  9:24   ` Daniel P. Berrangé
2024-10-31 19:38     ` Pierrick Bouvier
2024-11-04 15:58   ` Peter Maydell
2024-11-04 16:08     ` Michael S. Tsirkin
2024-11-04 22:09       ` Pierrick Bouvier
2024-11-04 22:05     ` Pierrick Bouvier
2024-11-05 10:15       ` Peter Maydell
2024-11-06 17:13 ` [PATCH 00/12] Enable building plugins on Windows with Clang Pierrick Bouvier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2831cc99-b2c3-414f-9a81-0e39e8dc6d34@linaro.org \
    --to=pierrick.bouvier@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=erdnaxe@crans.org \
    --cc=jsnow@redhat.com \
    --cc=kkostiuk@redhat.com \
    --cc=ma.mandourr@gmail.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=martin@martin.st \
    --cc=michael.roth@amd.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).