[ipxe-devel] Upcoming gcc 9 has issues with ipxe source

[Michael Brown]

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