| Message ID | 2a1cd614717f323afc788e24fae76337cffa8816.1489534345.git.raj.khem@gmail.com |
|---|---|
| State | Accepted |
| Commit | 2b1e9ddb10d4766cc4f8be3e55e4fc3d2810bbcb |
| Headers | show |
| Series | mesa/go/binutils fixes | expand |
On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> 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 Jussi -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Mon, 2017-03-20 at 10:32 +0200, Jussi Kukkonen wrote: > > On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> 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 That looks like a good guess. I had tried to reproduce that error last week with poky/master-next, but somehow it didn't trigger in my local setup. I have no idea how to enhance ovmf such that can handle this, though. Holding back an update of musl until someone can figure it out does not very attractive. But nor is disabling the building of ovmf when musl is selected, because then the wic tests which rely on ovmf will fail or also need to get disabled. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Mon, Mar 20, 2017 at 1:32 AM, Jussi Kukkonen <jussi.kukkonen@intel.com> wrote: > > On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> 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" > ? > Dont understand why musl would affect here. its using native gcc to build the artifacts its complaining about, > https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio > > > Jussi -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Mon, 2017-03-20 at 22:02 +0100, Patrick Ohly wrote: > 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. I've cleaned up the patch a bit more and tested it successfully with refkit on intel-corei7-64. Building for musl on qemux86 also worked, using i586-poky-linux-musl-gcc. I propose that we include the patch (will send as reply) in master-next to check whether it also fixes the problem on the AB. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Tue, Mar 21, 2017 at 1:56 AM, Patrick Ohly <patrick.ohly@intel.com> wrote: > 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. > FWIW this patch looks good. > Probably the entire split into ovmf-native and ovmf could be > removed. This merely hasn't been attempted yet. > > Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> > --- > 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 > > diff --git a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch > deleted file mode 100644 > index 644b99d..0000000 > --- a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch > +++ /dev/null > @@ -1,48 +0,0 @@ > -From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001 > -From: Matt Fleming <matt.fleming@intel.com> > -Date: Fri, 27 Jun 2014 11:12:18 +0100 > -Subject: [PATCH] BaseTools: Force tools variables to host toolchain > - > -Signed-off-by: Matt Fleming <matt.fleming@intel.com> > ---- > - 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 > - > diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb > index a658c9d..898c5b7 100644 > --- a/meta/recipes-core/ovmf/ovmf_git.bb > +++ b/meta/recipes-core/ovmf/ovmf_git.bb > @@ -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 > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index 7156669064..fa87d7d3e3 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -3,7 +3,7 @@ require musl.inc -SRCREV = "827c4e6fbe46142049ef3d8bcb8f35951712797d" +SRCREV = "cb525397bb053ea49cf160965477a17b17286eb3" PV = "1.1.16+git${SRCPV}"
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 Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-core/musl/musl_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.12.0 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core