[Xen-devel] [ovmf baseline-only test] 71428: tolerable FAIL

[Platform Team regression test user <citrix-osstest@xxxxxxxxxxxxxx>]

This run is configured for baseline tests only.

flight 71428 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71428/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt           5 libvirt-build                fail   like 71426
 build-i386-libvirt            5 libvirt-build                fail   like 71426

version targeted for testing:
 ovmf                 0fff7d6740419417b65361529612a49a6a2b96b2
baseline version:
 ovmf                 a0284a9a5820e470bae2557a7e25c426e62c8a4e

Last test of basis    71426  2017-05-24 20:19:12 Z    0 days
Testing same since    71428  2017-05-25 04:49:24 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Leif Lindholm <leif.lindholm@xxxxxxxxxx>
  Michael D Kinney <michael.d.kinney@xxxxxxxxx>
  Michael Kinney <michael.d.kinney@xxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
    http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.

------------------------------------------------------------
commit 0fff7d6740419417b65361529612a49a6a2b96b2
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue May 23 12:22:37 2017 -0700

    MdeModulePkg/DebugSupportDxe: Fix XCODE5 build failure
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=572
    
    Update X64 AsmFuncs.S to resolve a build failure using the
    XCODE5 tool chain.  This change updates AsmFuncs.S to match
    AsmFuncs.asm and AsmFuncs.nasm.
    
    The error generated in XCODE5 build is:
    
    error: invalid instruction mnemonic 'movzxw'
        movzxw 8(%rax), %rax
        ^~~~~~
    
    The correct instruction is
    
        movzwq 8(%rax), %rax
    
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Andrew Fish <afish@xxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit c8206f22fd2fb6e72c291304d38d8d1ddee732ce
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue May 23 12:03:39 2017 -0700

    MdeModulePkg/RegularExpressionDxe: Fix XCODE5 build failure
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=572
    
    The ErrorMessage local variable in OnigurumaMatch() should
    be type OnigUChar instead of type CHAR8.  This resolves
    a build failure with the XCODE5 tool chain.
    
    Cc: Andrew Fish <afish@xxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Andrew Fish <afish@xxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 00b00cc57bfe0fca54c904d4dd44a263e243c88b
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Fri May 19 11:47:40 2017 +0100

    BaseTools/Scripts: discard .gnu.hash section in GCC builds
    
    Some builds of GCC/binutils will default to using the GNU flavor of
    the symbol hash table, and will emit it into a section called .gnu.hash
    rather than .hash. We have no use for its contents, and GenFw ignores
    it anyway, so it shouldn't really matter what we do with it.
    
    However, due to a workaround for AARCH64 we have in GenFw to deal with
    older GCCs that corrupt section-based relocations when merging sections
    during the final link, we need the ELF and PE/COFF views of the binary
    to be identical. Since we don't place the .gnu.hash section explicitly,
    it may end up at the beginning of the ELF binary, causing other sections
    to be shifted in the ELF view but not in the PE/COFF view.
    
    So let's add .gnu.hash to the GCC linker script. We don't care about its
    contents so add it to the /DISCARD/ section.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Tested-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel