* [ovmf baseline-only test] 66888: trouble: blocked/broken/pass
@ 2016-08-02 20:13 Platform Team regression test user
0 siblings, 0 replies; only message in thread
From: Platform Team regression test user @ 2016-08-02 20:13 UTC (permalink / raw)
To: xen-devel, osstest-admin
This run is configured for baseline tests only.
flight 66888 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66888/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 3 host-install(3) broken REGR. vs. 66885
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 8134f7d9d2654a49916f627783c956f3eca78421
baseline version:
ovmf 28ade7b802e0732cf9839017ee6e9cf78b842582
Last test of basis 66885 2016-08-02 10:48:15 Z 0 days
Testing same since 66888 2016-08-02 17:48:24 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ard Biesheuvel <ard.biesheuvel@linaro.org> # ARM
Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek <lersek@redhat.com>
Leif Lindholm <leif.lindholm@linaro.org> # AArch64
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 broken
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
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
broken-step build-amd64-pvops host-install(3)
Push not applicable.
------------------------------------------------------------
commit 8134f7d9d2654a49916f627783c956f3eca78421
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Tue Aug 2 11:16:44 2016 +0200
ShellBinPkg Arm/AArch64 Shell binary update
The binaries of ShellBinPkg are generated with ShellPkg from b89919ee8f8c
("BaseTools AARCH64: override XIP module linker alignment to 32 bytes")
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org> # AArch64
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ARM
commit b89919ee8f8c9441c3514a3c5f352c0901103569
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Wed Jul 27 12:08:20 2016 +0200
BaseTools AARCH64: override XIP module linker alignment to 32 bytes
Now that GenFw converts small code model ADRP instructions to ADR on
the fly, we can reduce the alignment for XIP modules, where large
alignment values may cause considerable waste of flash space due to
excessive padding. This limits the module size to 1 MB, but this is
not a concern in practice.
So set the XIP section alignment to 0x20 for DEBUG_GCC49, DEBUG_GCC5
and *_CLANG35, all of which use the small code model.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
commit 026a82abf0bd6268d32f4559dbede00715264f74
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Tue Jul 26 16:37:37 2016 +0200
BaseTools/GenFw AARCH64: convert ADRP to ADR instructions if binary size allows it
The ADRP instruction in the AArch64 ISA requires the link time and load time
offsets of a binary to be equal modulo 4 KB. The reason is that this instruction
always produces a multiple of 4 KB, and relies on a subsequent ADD or LDR
instruction to set the offset into the page. The resulting symbol reference
only produces the correct value if the symbol in question resides at that
exact offset into the page, and so loading the binary at arbitrary offsets
is not possible.
Due to the various levels of padding when packing FVs into FVs into FDs, this
alignment is very costly for XIP code, and so we would like to relax this
alignment requirement if possible.
Given that symbols that are sufficiently close (within 1 MB) of the reference
can also be reached using an ADR instruction which does not suffer from this
alignment issue, let's replace ADRP instructions with ADR after linking if
the offset can be encoded in this instruction's immediate field. Note that
this only makes sense if the section alignment is < 4 KB. Otherwise,
replacing the ADRP has no benefit, considering that the subsequent ADD or
LDR instruction is retained, and that micro-architectures are more likely
to be optimized for ADRP/ADD pairs (i.e., via micro op fusing) than for
ADR/ADD pairs, which are non-typical.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
commit 4a8466d4babab43ee6ee46e37c2abb8248661ad5
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Sun Jul 17 23:20:10 2016 +0200
BaseTools GCC: introduce GCC5 toolchain to support GCC v5.x in LTO mode
This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and
AARCH64. Due to the fact that the GCC project switched to a new
numbering scheme where the first digit is now incremented for every
major release, the new toolchain is simply called 'GCC5', and is
intended to support all GCC v5.x releases.
Since IA32 and X64 enable compiler optimizations (-Os) for both DEBUG
and RELEASE builds, LTO support is equally enabled for both targets.
On ARM and AARCH64, DEBUG builds are not optimized, and so the LTO
optimizations are only enabled for RELEASE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
commit 7fd5d619806df5e5b9bdbd0cfe14580040ea3615
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Wed Jul 27 11:13:58 2016 +0200
BaseTools GCC: drop GNU notes section from EFI image
Recent versions of GNU ld automatically emit a .notes section into
the ELF binary containing a build id. Since this is an allocatable
section by default, it will be identified by GenFw as a section
that requires PE/COFF conversion, which may cause sections to be
moved around unexpectedly.
So retain the section, but tag it as INFO, which tells the linker
that it should not be accounted for in the binary's memory layout.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
commit e1458aaded8e34b0c74c1a17ac1dc3765d97c082
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Mon Jul 18 12:19:34 2016 +0200
ArmPkg: add prebuilt glue binaries for GCC5 LTO support
GCC in LTO mode interoperates poorly with non-standard libraries that
provide implementations of compiler intrinsics such as memcpy/memset
or the stack protector entry points. Such libraries need to be built
in non-LTO mode, and then referenced explicitly on the linker command
line using a -plugin-opt=-pass-through=-lxxx linker option.
However, if these intrinsics are also referenced directly, the LTO
version of the code will be pulled in, and will happily satisfy all
other references to the same symbol.
So add a pair of glue libraries, for ARM and AARCH64, that reference
the known intrinsics. Since the binaries live under ArmPkg directly,
we can reference them in tools_def.txt. Under LD garbage collection,
the object itself will be pruned, and so will the intrinsics that end
up unused by the module.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
commit a1b8baccc30ba7c3911359e271b0e0a3ef56d501
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Sat Jul 23 10:19:46 2016 +0200
BaseTools GCC: use 'gcc' as the linker command for GCC44 and later
To accommodate upcoming GCCx toolchain versions that require 'gcc' to
be used as the linker in order to support LTO, switch GCC44 and later
(including CLANG35) to a new DLINK build rule that invokes 'gcc' as the
linker instead of 'ld'. Since gcc expects its command line arguments in
a different format, and expects arguments that it needs to pass to the
linker to be prefixed with '-Wl,', this involves changes to most of the
DLINK_FLAGS definitions in tools_def.template, as well as some changes to
module .INF files that set their own linker options.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
commit befb3ba5150200ce94044c8c27e6e812d8e89680
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Sat Jul 23 08:18:31 2016 +0200
BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into GCCLD
Before we can make non-backward compatible changes to the GCC build rules
regarding the use of the 'gcc' binary as the linker, clone the existing
GCC build rules into a 'GCCLD' build rule family, and move the legacy
toolchains UNIXGCC, CYGGCC, CYGGCCxASL and ELFGCC over to it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
commit ff54bcdf2e4e07d91e6568953d3af359fd6b5586
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Sat Jul 23 10:14:11 2016 +0200
ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note sections
Newer versions of ld automatically emit .gnu.hash and .note.gnu.build-id
sections, which are not listed in the linker script, and will end up
breaking the build with an allocation conflict, e.g.,
/usr/bin/aarch64-linux-gnu-ld: section .note.gnu.build-id loaded at
[0000000000000000,0000000000000023] overlaps section .text loaded at
[0000000000000000,0000000000017dbf]
Since we don't require or care about these sections, update the linker
script so that they are discarded. Note that this involves emitting the
.note.gnu.build-id section into a non-allocatable segment to prevent the
linker from noticing that it is being discarded (and subsequently
complaining about it)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
commit 1c63516075b3d7e06a8919b030afdef3116d6373
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Sat Jul 23 09:38:14 2016 +0200
BaseTools CLANG35: drop problematic use-movt and save-temps options
Some versions of Clang fail on every input file when using the
-save-temps options, and produces the following heplful error message:
<unknown>:0: error: Undefined temporary symbol
Simply dropping the option for CLANG35 is the simplest way around this,
since the value of storing .i and .s files is dubious anyway.
Also, drop the arm-use-movt option, which does not appear to be
supported anymore by recent versions of clang.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-08-02 20:13 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-02 20:13 [ovmf baseline-only test] 66888: trouble: blocked/broken/pass Platform Team regression test user
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).