[Xen-devel] [ovmf baseline-only test] 66958: all pass

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 1fbd0ca16a997b68ed320340aef18645e71e8a73
baseline version:
 ovmf                 9e730bd16418d76e400f87cf852b53f960d1d5b3

Last test of basis    66948  2016-08-09 10:19:59 Z    1 days
Testing same since    66958  2016-08-10 03:19:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 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 1fbd0ca16a997b68ed320340aef18645e71e8a73
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Aug 8 13:03:46 2016 +0200

    StdLib/LibC ARM AARCH64: do not redefine compiler intrinsics
    
    The memset() function is a compiler intrinsic on AARCH64 and ARM, and
    so is memmove() on ARM. Usually, redefining them as LibC currently does
    is not a problem since only one version will be selected at link time
    from the various static libraries that provide implementations. However,
    under LTO, this is slightly different, since explicit references (in the
    C code) and implicit references (emitted by the compiler backend) may
    resolve to different versions (LTO vs non-LTO), causing conflicts.
    
    So simply omit them for ARM/AARCH64 resp. ARM.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Jaben Carsey <jaben.carsey@xxxxxxxxx>

commit 78d706e23512435c8166afe88600c4de493e0e68
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Aug 8 12:46:50 2016 +0200

    StdLib/LibC: avoid LTO code for compiler intrinsics
    
    The softfloat routines and some other routines supplied by LibC
    will satisfy references to compiler intrinsics that are emitted
    by the compiler backend, which under LTO means that the link-time
    code generation may emit references to symbols that have been
    optimized away already.
    
    Work around this by building the ARM and AARCH64 versions of LibC
    and the softfloat library without LTO.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Michael Zimmermann <sigmaepsilon92@xxxxxxxxx>
    Reviewed-by: Jaben Carsey <jaben.carsey@xxxxxxxxx>

commit 0f73cca02b645267cb11ab8ddf1ba88af5ec3246
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Aug 8 12:33:06 2016 +0200

    BaseTools ARM: impose strict alignment only for XIP modules
    
    Given that we only support ARMv7 and up in Tianocore (due to the fact
    that the PI spec mandates that the PEI services table pointer be stored
    in the TPIDRURW register, which is not available on earlier CPUs), we can
    assume that any code executing with the MMU on may perform unaligned
    accesses (since the AArch32 bindings in the UEFI spec stipulate that
    unaligned accesses should be allowed if supported by the CPU)
    
    So relax the alignment restrictions to XIP modules only, i.e., BASE, SEC,
    PEI_CORE and PEIM type modules, exactly like we do for AARCH64 already.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit 3cdbd7528bd46584551de60f3c47e63963dda117
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Aug 8 11:58:59 2016 +0200

    BaseTools CLANG35: add missing XIP flags for AARCH64
    
    When building for AARCH64, code that may execute with the MMU off should
    not perform unaligned accesses, which is why we set -mstrict-align for
    BASE, SEC, PEI_CORE and PEIM modules when building with GCCx. However,
    this setting is missing from CLANG35 so set it there as well.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

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