mesa/go/binutils fixes

Currently we enable threaded linking feature of gold linker only when its used as default ld. There is no need to restrict it when its not default linker either. As long as gold is enabled, which is the case here, we should be able to do threaded linking.

Rich Felker (11):
fix ld-behavior-dependent crash in ppc64 ldso startup rework ldso handling of global symbol table for consistency reorder addend handling before symbol lookup in relocation code emulate lazy relocation as deferrable relocation
fix free of uninitialized buffer pointer on error in regexec in static dl_iterate_phdr, fix use of possibly-uninitialized aux data fix possible fd leak, unrestored cancellation state on dns socket
fail
fix wide scanf's use of a compound literal past its lifetime fix one-byte overflow in legacy getpass function
avoid loading of multiple libc versions via explicit pathname remove unused refcnt field for shared libraries

Szabolcs Nagy (1):
treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym

On 15 March 2017 at 01:35, Khem Raj <[email protected]> wrote:
Rich Felker (11):
fix ld-behavior-dependent crash in ppc64 ldso startup rework ldso handling of global symbol table for
consistency
reorder addend handling before symbol lookup in
relocation code
emulate lazy relocation as deferrable relocation fix free of uninitialized buffer pointer on error in
regexec
in static dl_iterate_phdr, fix use of
possibly-uninitialized aux data
fix possible fd leak, unrestored cancellation state on
dns socket fail
fix wide scanf's use of a compound literal past its
lifetime
fix one-byte overflow in legacy getpass function avoid loading of multiple libc versions via explicit
pathname
remove unused refcnt field for shared libraries

Szabolcs Nagy (1):
treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in
find_sym

Could the relocation changes here be responsible for these ovmf build failures:
"GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
?

https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio

Quoted 16 lines · Khem Raj

Rich Felker (11):
fix ld-behavior-dependent crash in ppc64 ldso startup rework ldso handling of global symbol table for consistency reorder addend handling before symbol lookup in relocation code emulate lazy relocation as deferrable relocation
fix free of uninitialized buffer pointer on error in regexec in static dl_iterate_phdr, fix use of possibly-uninitialized aux
data
fix possible fd leak, unrestored cancellation state on dns socket
fail
fix wide scanf's use of a compound literal past its lifetime fix one-byte overflow in legacy getpass function
avoid loading of multiple libc versions via explicit pathname remove unused refcnt field for shared libraries

Quoted 2 lines

Szabolcs Nagy (1):
treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym

Could the relocation changes here be responsible for these ovmf build failures:
"GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
?

https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio

Jussi

Quoted 23 lines · Jussi Kukkonen

Quoted 18 lines · Khem Raj

Rich Felker (11):
fix ld-behavior-dependent crash in ppc64 ldso startup rework ldso handling of global symbol table for consistency reorder addend handling before symbol lookup in relocation code emulate lazy relocation as deferrable relocation
fix free of uninitialized buffer pointer on error in regexec in static dl_iterate_phdr, fix use of possibly-uninitialized aux
data
fix possible fd leak, unrestored cancellation state on dns socket
fail
fix wide scanf's use of a compound literal past its lifetime fix one-byte overflow in legacy getpass function
avoid loading of multiple libc versions via explicit pathname remove unused refcnt field for shared libraries

Szabolcs Nagy (1):
treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym

Quoted 5 lines

Could the relocation changes here be responsible for these ovmf build failures:
"GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
?

Dont understand why musl would affect here.
its using native gcc to build the artifacts its complaining about,

However, TARGET_PREFIX is empty in ovmf-native. So instead of i586-poky-linux-musl-gcc or i586-poky-linux-musl-gcc-ar we end up building with gcc and gcc-ar from the host, which probably wasn't the intention.

Below a patch which compiles for me using the right tools. More testing has to wait until tomorrow.

For the native tools, a static patch inserted gcc/g++/ld/ar while later adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed, which has the advantage that it uses the actual compile variables. However, in practice those are the same.

More importantly, picking the build tools for the target was broken. ovmf-native tried to insert TARGET_PREFIX into the tools definition file, but that variable is empty in a native recipe. As a result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an undesirable dependency on the host compiler and potentially (probably?!) causing some of the build issues that were seen for ovmf.

The new approach is to override the tool selection in ovmf-native so that the HOST_PREFIX env variable is used, which then gets exported during do_compile for the target.

While at it, Python code that gets appened to do_patch only to call shell functions gets replaced with the do_patch[postfuncs] mechanism.

Incremental builds now always use the tools definition from the current ovmf-native; previously, only the initial build copied the template file.

Probably the entire split into ovmf-native and ovmf could be removed. This merely hasn't been attempted yet.

Signed-off-by Patrick Ohly <[email protected]>

---
 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch | 48 ------------------------------------------------
 meta/recipes-core/ovmf/ovmf_git.bb                                                       | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++------------------
 2 files changed, 50 insertions(+), 66 deletions(-)
 delete mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch

meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch deleted +0 -48

deleted file mode 100644
index 644b99d..0000000
@@ -1,48 +0,0 @@
-From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001
-From: Matt Fleming <[email protected]>
-Date: Fri, 27 Jun 2014 11:12:18 +0100
-Subject: [PATCH] BaseTools: Force tools variables to host toolchain
-
-Signed-off-by: Matt Fleming <[email protected]>
----
- BaseTools/Source/C/Makefiles/app.makefile | 7 +++++++
- BaseTools/Source/C/VfrCompile/GNUmakefile | 5 +++++
- 2 files changed, 12 insertions(+)
-
-diff --git a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile
-index 19269a1..62aad0f 100644
---- a/BaseTools/Source/C/Makefiles/app.makefile
-+++ b/BaseTools/Source/C/Makefiles/app.makefile
-@@ -16,6 +16,13 @@ include $(MAKEROOT)/Makefiles/header.makefile
-
- APPLICATION = $(MAKEROOT)/bin/$(APPNAME)
-
-+CC = gcc
-+CXX = g++
-+AS = gcc
-+AR = ar
-+LD = ld
-+LINKER = $(CC)
-+
- .PHONY:all
- all: $(MAKEROOT)/bin $(APPLICATION)
-
-diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile
-index 82005e1..5ac5f7e 100644
---- a/BaseTools/Source/C/VfrCompile/GNUmakefile
-+++ b/BaseTools/Source/C/VfrCompile/GNUmakefile
-@@ -26,6 +26,11 @@ OBJECTS = AParser.o DLexerBase.o ATokenBuffer.o EfiVfrParser.o VfrLexer.o VfrSyn
-
- VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(CPPFLAGS)
-
-+CC = gcc
-+CXX = g++
-+AS = gcc
-+AR = ar
-+LD = ld
- LINKER = $(BUILD_CXX)
-
- EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h
---
-1.9.0
-

meta/recipes-core/ovmf/ovmf_git.bb +50 -18

index a658c9d..898c5b7 100644
@@ -11,7 +11,6 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[secureboot] = ",,,"
 
 SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
-       file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch \
        file://0002-ovmf-update-path-to-native-BaseTools.patch \
        file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
        file://VfrCompile-increase-path-length-limit.patch \

@@ -51,31 +50,54 @@ COMPATIBLE_HOST='(i.86|x86_64).*'
 OVMF_SECURE_BOOT_EXTRA_FLAGS ??= ""
 OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE ${OVMF_SECURE_BOOT_EXTRA_FLAGS}"
 
-do_patch_append_class-native() {
-    bb.build.exec_func('do_fix_iasl', d)
-    bb.build.exec_func('do_fix_toolchain', d)
+do_patch[postfuncs] += "fix_basetools_location"
+fix_basetools_location () {
 }
-
-do_fix_basetools_location() {
+fix_basetools_location_class-target() {
+    # Replaces the fake path inserted by 0002-ovmf-update-path-to-native-BaseTools.patch.
+    # Necessary for finding the actual BaseTools from ovmf-native.
     sed -i -e 's#BBAKE_EDK_TOOLS_PATH#${STAGING_BINDIR_NATIVE}/${EDK_TOOLS_DIR}#' ${S}/OvmfPkg/build.sh
 }
 
-do_patch_append_class-target() {
-    bb.build.exec_func('do_fix_basetools_location', d)
+do_patch[postfuncs] += "fix_iasl"
+fix_iasl() {
 }
-
-
-do_fix_iasl() {
+fix_iasl_class-native() {
+    # iasl is not installed under /usr/bin when building with OE.
     sed -i -e 's#/usr/bin/iasl#${STAGING_BINDIR_NATIVE}/iasl#' ${S}/BaseTools/Conf/tools_def.template
 }
 
-do_fix_toolchain(){
-    sed -i -e 's#DEF(ELFGCC_BIN)/#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
-    sed -i -e 's#DEF(GCC.*PREFIX)#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+# Inject CC and friends into the build. LINKER already is in GNUmakefile.
+# Must be idempotent and thus remove old assignments that were inserted
+# earlier.
+do_patch[postfuncs] += "fix_toolchain"
+fix_toolchain() {
+    sed -i \
+        -e '/^\(CC\|CXX\|AS\|AR\|LD\|LINKER\) =/d' \
+        -e '/^APPLICATION/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}\nLINKER = $(CC)' \
+        ${S}/BaseTools/Source/C/Makefiles/app.makefile
+    sed -i \
+        -e '/^\(CC\|CXX\|AS\|AR\|LD\)/d' \
+        -e '/^VFR_CPPFLAGS/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}' \
+        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+}
+fix_toolchain_append_class-native() {
+    # This tools_def.template is going to be used by the target ovmf and
+    # defines which compilers to use. For the GCC toolchain definitions,
+    # that will be ${HOST_PREFIX}gcc. However, "make" doesn't need that
+    # prefix.
+    #
+    # Injecting ENV(HOST_PREFIX) matches exporting that value as env
+    # variable in do_compile_class-target.
+    sed -i \
+        -e 's#\(ENV\|DEF\)(GCC.*_PREFIX)#ENV(HOST_PREFIX)#' \
+        -e 's#ENV(HOST_PREFIX)make#make#' \
+        ${S}/BaseTools/Conf/tools_def.template
+    sed -i \
+        -e '/^\(LFLAGS\|CFLAGS\) +=/d' \
+        -e '/^LINKER/a LFLAGS += ${BUILD_LDFLAGS}\nCFLAGS += ${BUILD_CFLAGS}' \
+        ${S}/BaseTools/Source/C/Makefiles/app.makefile \
+        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
 }
 
 GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"

@@ -119,6 +141,16 @@ do_compile_class-target() {
         OVMF_ARCH="IA32"
     fi
 
+    # The build for the target uses BaseTools/Conf/tools_def.template
+    # from ovmf-native to find the compiler, which depends on
+    # exporting HOST_PREFIX.
+    export HOST_PREFIX="${HOST_PREFIX}"
+
+    # BaseTools/Conf gets copied to Conf, but only if that does not
+    # exist yet. To ensure that an updated template gets used during
+    # incremental builds, we need to remove the copy before we start.
+    rm -f `ls ${S}/Conf/*.txt | grep -v ReadMe.txt`
+
     # ${WORKDIR}/ovmf is a well-known location where do_install and
     # do_deploy will be able to find the files.
     rm -rf ${WORKDIR}/ovmf

base-commit: 30bea167e7c204be52b3f5af24e43d5f339e98b7 --
git-series 0.9.1
--
_______________________________________________
Openembedded-core mailing list [email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core