OvmfPkg/IoMmuDxe: unused-const-variable warning fails release build with GCC 6.3

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Hi,

commit 2ad6ba80a1bd58382bde6b994070f7c01d2fb48d
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Wed Aug 30 14:00:58 2017 +0200

     OvmfPkg/IoMmuDxe: IoMmuMap(): log nicer and more informative DEBUG msgs

triggers a unused-const-variable warning for mBusMasterOperationName,
and thus for releases with warnings-as-errors a build error.

I'm using a quite vanilla Debian Stretch machine on amd64/x86_64 (running
in qemu/KVM) as build host, gcc version is 6.3.0 20170516 (Debian 6.3.0-18)

My build procedure looks like:

# make -C BaseTools/
# . edksetup.sh
# OvmfPkg/build.sh -a X64 -b RELEASE -n 4 -t GCC5

With current master (12cfc9009e7cf1a69ca675110c2cf6e21b152992) checked out.

I suspect that gcc, at least in this version, cannot track the usage of the
variable in crime in the DEBUG macros, and thus (falsely?) detects this warning.

So I'm not quite sure if this is a problem with edk2/Ovmf itself or a problem
stemming from gcc.

The following patch fixes the problem quite nonchalantly by adding an unused
attribute, which is highly probably not what is wanted as a clean fix -
I guess - but it achieves my desired result :)

----8<----
diff --git a/OvmfPkg/IoMmuDxe/AmdSevIoMmu.c b/OvmfPkg/IoMmuDxe/AmdSevIoMmu.c
index bc57de5b57..8c0b8b0931 100644
--- a/OvmfPkg/IoMmuDxe/AmdSevIoMmu.c
+++ b/OvmfPkg/IoMmuDxe/AmdSevIoMmu.c
@@ -48,7 +48,7 @@ STATIC LIST_ENTRY mRecycledMapInfos = INITIALIZE_LIST_HEAD_VARIABLE (
  // ASCII names for EDKII_IOMMU_OPERATION constants, for debug logging.
  //
  STATIC CONST CHAR8 * CONST
-mBusMasterOperationName[EdkiiIoMmuOperationMaximum] = {
+mBusMasterOperationName[EdkiiIoMmuOperationMaximum] __attribute__ ((unused)) = {
    "Read",
    "Write",
    "CommonBuffer",
---->8----

It naturally could be that I've got something wrong, wouldn't be the first time,
but I suspect that it's edk2 in combination with my GCC version this time.
As I lack in depth knowledge of Ovmf it'd be nice if someone could confirm my
suspicion.

CC'ing Laszlo as he is the author of the patch which lets this problem
trigger and following this mailing list since a bit it seems that he surely
has the in depth knowledge.
Sorry that I wasn't patient enough to test other compiler version before
posting here.

cheers,
Thomas