Bug 216644 - emulators/xen-kernel: fails to build with clang 4.0
Summary: emulators/xen-kernel: fails to build with clang 4.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Roger Pau Monné
URL:
Keywords: needs-patch
Depends on:
Blocks: 216008
  Show dependency treegraph
 
Reported: 2017-01-31 00:19 UTC by Jan Beich
Modified: 2017-04-14 17:16 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (royger)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2017-01-31 00:19:06 UTC
vmx.c:973:38: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_CS_BASE,     &reg->base);
                                     ^~~~~~~~~
vmx.c:979:38: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_DS_BASE,     &reg->base);
                                     ^~~~~~~~~
vmx.c:985:38: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_ES_BASE,     &reg->base);
                                     ^~~~~~~~~
vmx.c:991:38: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_FS_BASE,     &reg->base);
                                     ^~~~~~~~~
vmx.c:997:38: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_GS_BASE,     &reg->base);
                                     ^~~~~~~~~
vmx.c:1003:38: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_SS_BASE,     &reg->base);
                                     ^~~~~~~~~
vmx.c:1009:38: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_TR_BASE,     &reg->base);
                                     ^~~~~~~~~
vmx.c:1014:37: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_GDTR_BASE,  &reg->base);
                                    ^~~~~~~~~
vmx.c:1018:37: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_IDTR_BASE,  &reg->base);
                                    ^~~~~~~~~
vmx.c:1023:40: error: taking address of packed member 'base' of class or structure 'segment_register' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
        __vmread(GUEST_LDTR_BASE,     &reg->base);
                                       ^~~~~~~~~


http://package18.nyi.freebsd.org/data/headamd64PR216008-default/2017-01-29_16h09m05s/logs/errors/xen-kernel-4.7.1_3.log
Comment 1 Roger Pau Monné freebsd_committer 2017-02-01 10:11:13 UTC
It's really stupid for clang to do this, the more when:

1. x86 supports unaligned accesses.
2. Those fields are not actually unaligned.

I will add "-Wno-address-of-packed-member" somewhere...

But really, this check is pointless.
Comment 2 Roger Pau Monné freebsd_committer 2017-02-01 11:37:25 UTC
After speaking with the llvm guys, it seems like this warning was refined later on, in order to avoid having so many false positives, could we please apply:

https://reviews.llvm.org/rL283304
https://reviews.llvm.org/rL286798

And have another try at the Xen packages?

(the first patch is only required for the second one to apply cleanly).
Comment 3 Jan Beich freebsd_committer 2017-02-01 12:19:58 UTC
/projects/clang400-import has both LLVM r283304 and r286798 but Dimitry may know exactly when 4.0 branched upstream or how to fix the fallout from -Waddress-of-packed-member.
Comment 4 Dimitry Andric freebsd_committer 2017-02-01 13:36:34 UTC
(In reply to Roger Pau Monné from comment #2)
> After speaking with the llvm guys, it seems like this warning was refined
> later on, in order to avoid having so many false positives, could we please
> apply:
> 
> https://reviews.llvm.org/rL283304
> https://reviews.llvm.org/rL286798

The 4.0 release branch should already have those, it was branched off of trunk r291814:
------------------------------------------------------------------------
r291817 | hans | 2017-01-12 22:25:25 +0100 (Thu, 12 Jan 2017) | 1 line

Creating release_40 branch off revision 291814
------------------------------------------------------------------------


(In reply to Jan Beich (mail not working) from comment #3)
> /projects/clang400-import has both LLVM r283304 and r286798 but Dimitry may
> know exactly when 4.0 branched upstream or how to fix the fallout from
> -Waddress-of-packed-member.

I think it's probably best to squelch the warning.  Meanwhile an upstream PR would be nice, because this warning is indeed still way too trigger-happy, even after those revisions above.
Comment 5 Roger Pau Monné freebsd_committer 2017-02-01 13:41:24 UTC
I'm already interacting with them at:

https://reviews.llvm.org/D20561

But I have the feeling that no one really knows exactly what should trigger from this option, and TBH, I think it's useless. There are many ways that could trigger unaligned accesses, and there's no way you are going to catch them all from the compiler anyway.
Comment 6 Roger Pau Monné freebsd_committer 2017-04-14 17:16:55 UTC
Solved.