[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 13 Sep 2021 15:37:04 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LZ2FW8Iaupoo8E88XIF+kizmAFZvLvu+996YnALcNfw=; b=GTgYQJsRmxd2LQRglQM6DSvDDTLAD06CJaCFMdRIJnXHK5sDNErtbtfPSwxPocGlG4AzfmhtQODKpe9V68OBlr0A4sjYKJgrhdEBdBTXTP9m6bn4DzaqBmlekGv2EWn5jBLhgDUi8kmd7sNd3QifvPoSbDlAq4+s3ke3PTYWDl9bfgSpWYgAijfu8co07Gv5KKE+sX7kU/bv4bD36p3HbzyIC6K9teCPAKXk/4TzBZLn/kaplOrbNDM3Zm96NDa8x2cDF3yKGfo3r5OFOqp6VKmeDpHzOcSduLyqokJmw/cS9txCzXQI9XfQbvIuulClxoqdzkfiBS3V1XPANh2nnw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VF5oiJ6R5sijX4YDGm28IYTBz83U/nNUL8BVN8FBVUtQtBokBuDUfzMigWK+6/Pm4YrCB2VSfrWuGc1zGBrJyGkOeVqVO7orj8ZcqQjj4g1lsB1YJAh8UuIaCxpUC34P3PYPFu+25bhs+68M+Ouu2IZ08f/URtRjLWwq2uZhcxDTb74JBiQC3L3vQbUrZT+llWw0sgBr9AXS7k4NN+aIcl3dLgiuEzx4XxrfEcXfBaPKFnaTzw3rKQLdjf8c/eZFf6PdEr59SN/XPgZ56SzH7EU8aH5tfvJ7PMaLrI9gJNNfrLQu0w58r9UrsMY4mKP06hxT95wvTfgNlxUR9JD/uQ==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 13 Sep 2021 13:37:22 +0000
  • Ironport-data: A9a23:Rx5M3qocUl//bMAVBQCs1HAJX5BeBmIGYhIvgKrLsJaIsI4StFCzt garIBmFOP7fM2v0KNh3b4yx8EkAvcKAytFqQANqryA3En5D85uZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlZT4vE2xbuKU5NTsY0idfic5Dnd84f5fs7Rh2Ncw0IHiW1nlV e7a+KUzBnf0g1aYDUpMg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJ8DO+iL 9sv+Znilo/vE7XBPfv++lrzWhVirrc/pmFigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnZj3RFoEYpLQpP1HCRUGSHw5FJ0W9KCSdBBTseTLp6HHW37lwvEoB0AqJ4wIvO1wBAmi9 9RBdmpLNErawbvrnvTrEYGAhex6RCXvFJkYtXx6iynQEN4tQIzZQrWM7thdtNs1rp0UQKePO JVJAdZpRDfjbzlBGlY8M5gvmOGMvljBVzZfrF3A8MLb5ECMlVcsgdABKuH9ZdiiVchT2EGCq Qru72n/Rx0XKtGb4T6E6W63wP/CmzvhX4AfH6H+8eRl6HWRzGEODBwdVXOgvOK0zEW5Xrpix 1c8o3R06/JorQryE4e7D0bQTGO4UgA0X51dTsBm1x2x0/CO71jCWy8tfm5Nd4lz3CMpfgDGx mNljvuwW2c26ubIGC7CnluHhWjtYnlOdAfucQdBFFFcsoe5+OnfmzqSFo4LLUKjsjHi9dgcK RixpS4ijv04iccR3s1XFniW3mrx+vAlouMzjzg7v15JDCsiP+ZJhKTysDA3CMqsy67DEjG8U IAswZT20Qz3JcjleNaxrAAxIV1Uz6zdbG20baFT82kJqG32pi/LkXF4yzBiPkZ5Wvs5lcvSS BaL42t5vcYLVFPzNPMfS9/hWqwCkPm7ffy4B6+8Uza7SsUoHONx1Ho1PhD4MqGEuBVErJzTz r/CIZj1UidLVv09pNd0Ls9EuYIWKukF7Tq7bbjwzgi90KrYY3iQSLwfN0CJYPx/56SByDg5O f4FXydT4xkAAuD4fAfN9osfcQIDIXQhXMikoM1LbO+TZAFhHTh5WfPWxLogfa1jnrhUybiUr i3sBBcAxQqtn2DDJCWLdmtnNOHlU6FgoC9pJicrJ1uphSQuON798KcFepIrVrA77+g/n+VsR vwIdpzYUPRCQzjK4RoHapz5oNAwfRinn1vWbSGkfCI+b9hrQAmQoo3oeQ7m9S8vCCurtJRh/ +38h12DGZdaHlZsFsfbbv6r3midh3lFlbIgRVbML/lSZF7orNpgJRvug6JlOMoLMxjCmGeXj l7EHRcCqODRiIYp692V17ucpoKkHuYiTEpXG27XseS/OSXApzfxxIZBVKCDfCzHVXOy86KnP L0Hw/b5OfwBvVBLr4sjTOo7kfNgv4Pi9+1A0wBpPHTXdFD6WLpvL06P0dRLqqAQlKRSvhG7W x7X99RXUVlT1BgJzLLFyNIZU9m+
  • Ironport-hdrordr: A9a23:gkVGz63bTZplzaRg9HY27gqjBIgkLtp133Aq2lEZdPUzSL3/qy nOpoV96faQsl0ssR4b9exoVJPufZq+z/5ICOsqU4tKNTOO0AHEEGgI1+rfKlPbakjD398Y+a B8c7VvTP3cZGIK6foSOTPIcOrIFuP3kpyVuQ==
  • Ironport-sdr: KcVVgRw+8sBPkarTPr/I0O2TS92Kyj4JrknxGUSma8H0kUdWMz/eLg5Icnm/a6puOwFUkhoD/8 DXwS5DFlFhPkAJbcZ6zwUUxa3S8G7k92uOcGWhV66VB/6SJTHzdN4eVKzLLDbAv4b23u7oBC99 gJJikBt9hQmFqxiwnI+NLWj0RycoCqjgcKDdlv+ViR0Aa5w2+79xk95zOOhs1ofYExjXLuQfLL s3P0gwG8bA8+VqcJacB+AV3O8d2j1j/qxl0JX/EfkaI7eP13DOKmRky0ZA63XuXWJdREA0oZbX q+qiyair41kUf/1nhDtlRrh+
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote:
> While LLVM's lld is supposed to be a drop-in replacement for GNU ld [1],
> it appears to not understand quoted section names as operands to e.g.
> ADDR(). Therefore the original workaround broke the build in
> environments where ld is actually LLVM's, like on FreeBSD.
> 
> Fixes: 58ad654ebce7 ("x86: work around build issue with GNU ld 2.37")
> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flld.llvm.org%2F&amp;data=04%7C01%7Croger.pau%40citrix.com%7C07abc3240fc14a3f095408d9739f3eb3%7C335836de42ef43a2b145348c2ee9ca5b%7C0%7C0%7C637667950073151096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Sa0BBWP2cWOhWsB3b4FQIZ1J3KvfWP%2BnINiqyXdChD0%3D&amp;reserved=0
> ---
> I haven't been able to find an environment where I could actually try
> with lld (ld.lld); all testing was with GNU ld (ld.bfd).

Thanks for fixing this. I've been able to test with LLVM ld and the
workaround is fine.

> --- a/.gitignore
> +++ b/.gitignore
> @@ -306,6 +306,7 @@
>  xen/.config.old
>  xen/.xen.elf32
>  xen/System.map
> +xen/arch/x86/.check.*
>  xen/arch/x86/asm-macros.i
>  xen/arch/x86/boot/mkelf32
>  xen/arch/x86/boot/cmdline.S
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -92,10 +92,16 @@ efi-$(CONFIG_PV_SHIM_EXCLUSIVE) :=
>  
>  ifneq ($(build_id_linker),)
>  notes_phdrs = --notes
> +# Determine whether to engage a workaround for GNU ld 2.37.
> +build-id-ld-good = $(shell echo 'void test(void) {}' \
> +                           | $(CC) $(XEN_CFLAGS) -o .check.o -c -x c - 
> 2>.check.err \
> +                           && $(LD) -T check.lds -o .check.elf .check.o 
> 2>>.check.err \
> +                           && echo y)

Do we want to make this a Kconfig option (ie: LD_UNQUOTED_DASH) and
then use is here?

We already have compiler and assembler checks in x86/Kconfig, so it
would seem more natural to place it there.

>  else
>  ifeq ($(CONFIG_PVH_GUEST),y)
>  notes_phdrs = --notes
>  endif
> +build-id-ld-good := y
>  endif

I also wonder whether we need to make the quoting tied to the usage of
build-id. I guess we don't add sections with dashes and instead
use underscores, but it might be prudent to always quote to be on the
safe side if dashes are not supported.

>  
>  ifdef CONFIG_LIVEPATCH
> @@ -291,6 +297,10 @@ $(BASEDIR)/include/asm-x86/asm-macros.h:
>       $(call move-if-changed,$@.new,$@)
>  
>  efi.lds: AFLAGS-y += -DEFI
> +xen.lds: Makefile
> +ifneq ($(build-id-ld-good),y)
> +xen.lds: CFLAGS-y += -DQUOTE_SECTION_NAMES
> +endif
>  xen.lds efi.lds: xen.lds.S
>       $(CPP) -P $(call cpp_flags,$(a_flags)) -MQ $@ -o $@ $<
>  
> @@ -302,7 +312,7 @@ hweight.o: CFLAGS-y += $(foreach reg,cx
>  
>  .PHONY: clean
>  clean::
> -     rm -f *.lds *.new boot/*.o boot/*~ boot/core boot/mkelf32
> +     rm -f ???.lds *.new .check.* boot/*.o boot/*~ boot/core boot/mkelf32
>       rm -f asm-macros.i $(BASEDIR)/include/asm-x86/asm-macros.*
>       rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d $(BASEDIR)/.xen.elf32
>       rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/mkreloc
> --- /dev/null
> +++ b/xen/arch/x86/check.lds

I would maybe name this check-dash.lds, in case we need to add more ld
build tests.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.