On 23/01/2019 23:07, Bruce Rogers wrote:
An early look at gcc 9 compatibility with packages built in the OpenSUSE Build
Service
shows that the ipxe sources hit up against a new warning, which is documented
as follows:
-Waddress-of-packed-member, enabled by default, warns about an unaligned pointer
value from the address of a packed member of a struct or union.
This issue is reported in this openSUSE bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1121464
I started to create a patch to address the instance in the bug report, but then
found out
that taking the address of members in packed structures is fairly common in the
code,
so I figured I'd first ask if someone is already looking into this or what
solution would
be best.
It's probably reasonable to simply silence this warning in the make system,
since I don't
think moving to gcc 9 and ignoring this new warning adds risk, but it does
point out
a portability and performance issue with the code which may be worth fixing.
I'd be happy to help provide code fixes, but don't want to jump the gun if
people
think silencing the warning is the solution.
iPXE code typically marks any hardware- or protocol-defined structures
as packed to indicate that the compiler may not adjust the structure
layout. This includes marking structures that are intrinsically
naturally aligned anyway, such as hardware descriptor ring entries. As
far as I'm aware, there's no way to annotate a structure definition as
"this is already naturally aligned, but the compiler is still explicitly
forbidden from inserting padding", so we end up just marking it as packed.
We build only for i386, x86_64, arm, and aarch64, all of which support
unaligned accesses. In the case of arm and aarch64, the unaligned
accesses are handled via the MMU, which works since the UEFI
specification for those architectures requires the MMU to be enabled and
to support unaligned accesses.
It would be nice to have support for architectures with stricter
alignment requirements, but only if the code changes are relatively clean.
My guess is that silencing the warning is the most appropriate fix, but
I'd be interested to see a small sample of how the code could
potentially be changed to work with the warning enabled.
Thanks,
Michael
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
