[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: Tue, 14 Sep 2021 09:29:36 +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=dAY+uZGV42lpJtZXtU0lvoXV0hBjXdyR9G7jZEG1zJw=; b=DLaIVI9FIFDI/x4AeSp8/9z+iO5AGreVsVZqdDRZo5E7/j0fy3DSeH0NHRPM1lNZCm1zDlfJAsDDRGlN1yOSQc8VFUSQE/rSuWg28Xv4lVOKw32SNVFSP+sdaPysbYkb37YbjU9EkGKqDfWNXChk7jfaZzMnVIKd9f17REJc1K5hCCW1gd4a/HKtahAum9A8Gh58Sd76vjMi9Ef5+455TgEKwOJCSjLh1mxBAZnX8y5ZlSJ0ndSmAcJt/Q5MdFK4R5DBYHuvCWf5HBNu1N1TE/DKA6VFviVoMx9sqnic/JD8SQYY0Q0Gn24KNFCSEMT8n1Th5Pc0lOT/pQAw3hT4Eg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nten3braosCehQW+2h1iyRct6b6CASKHrcCeH2xLjtauiK9AWxMBpSyifa+sQKTh9re/AdwMfJHbDqsavNQtP8aEuPzXF4OYfdHZbI7Ccypa/tWSjgDYB1d0jmeiMi7QM/u4/F4Ink7D5BALWghd5JLDoMJBNqFIyjku+tyCcEB2svkEhj/HHeUyTqDT70C/VJWPW5hj6XNTbsBECjyPHOYA+IY/yxPl4oc8bb/h3uQABLY7qh8xX0fF6ZocyVqZKJDTy6+SF9NEL6aE5I3LVoBJH0s7C6cr2B4HcqbwhcOGMuCzhkmq90SIsP28R9oNnuzwV9nHBmEKNwRceTNeDA==
  • Authentication-results: esa5.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: Tue, 14 Sep 2021 07:29:55 +0000
  • Ironport-data: A9a23:3w9W0q8ooOcxYHUFmsi9DrUDnnmTJUtcMsCJ2f8bNWPcYEJGY0x3z TEcCmjXPa2MZ2KgLogkaoqx9hxQvMXXytA1TlRtrHg8E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si9AttENlFEkvU2ybuOU5NXsZ2YhGGeIdA970Ug6w79g3tYx6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPgs7 ex35LCtRT4KP6rKsflFUSAbHHphaPguFL/veRBTsOSWxkzCNXDt3+9vHAc9OohwFuRfWD8Us 6ZCcXZUM07F17neLLGTE4GAguw5K8bmJsUHs2xIxjDFF/c2B5vERs0m4PcFhm1s2pEeTZ4yY eIfewtjUQ2QZydjZA8aIcIAmdiWlnbgJmgwRFW9+vNsvjm7IBZK+KfpGMrYfJqNX8o9tlaVo CfK8nr0BjkeNceD0nyV/3S0nOjNkCjnHoUIG9WQ9PRnnVmSzWw7EwANWB2wpvzRt6Klc4sBc QpOoHNo9PVsshzwJjXgY/GmiCOhhyRNd8dcKs477wek1/LW2kWWXXdRG1atd+caWN8KqS0Cj wHSxomyWG0z79V5WlrGqezF9mra1Tw9aDZYPH5aF1NtD8zL/dlr5i8jWOqPB0JcYjfdIjj23 znChyw3nbx7YSUjhvjjoAyvb95BoPH0ou8JCuf/BTnNAuBRPtfNi2mUBb/zt6ooEWphZgPd1 EXoYuDHhAz0MX1oqBFhvc1XRO35jxp6DNEsqQE2RMRwn9hc01WiYZpR8FlDGaudCe5dIWWBS BaK4Wt5vcYPVFP3Pf4fS9/gUKwCkPm/fekJo9iJN7KilLAqL1TZlMyvDGbNt13QfL8Eyv1mY sbHLp/3VB73y81PlVKLegvU6pdyrggWzmLPX5HriROh1LuVfnmOTrkZdlCJa4gEAGms+W05K v5TaJmHzQtxSur7bnWF+IIfNwlSf3M6GYr3u4pccevaelhqH2QoCvnwx7I9etM6w/QJx7mQp nztCFVFzFffhGHcLVnYYH5Ud76yD410qmg2PHJwMA/wiWQje4um8IwWa4AzIes87OVmwPMtF 6sFdsyMD+5hUDPC/zhBP5DxoJY7LEaghB6UPjrjaz86JsYySwvM897iXw3u6ChRUXbn6Zpg+ +Wtj1qJT4ACSgJuCNftRMiul17h72IAnO9SXlfTJoUBckvb74U3eTf6ieU6Ip9QJEyblCeaz QufHTwRufLJ/90u6NDMiK2J89WpHu95EhYIFmXX9+/rZyzT/27lyo5cSueYOzvaUTqsqqmlY OxUydD6MeEGwwkW49YtTe4zwPJs/cbrqp9b0h9gTSfCYFmcA799JmWLgJtUvapXy74F4Qa7V ypjIDWB1Wll7C89LGMsGQ==
  • Ironport-hdrordr: A9a23:7YCuA6+3GiFC2hMV9bxuk+FLdb1zdoMgy1knxilNoENuHPBwxv rAoB1E73PJYVYqOE3Jmbi7Sc+9qFfnhONICO4qTMuftWjdyRGVxeRZjLcKrAeQfhEWmtQtsZ uINpIOd+EYbmIK/foSgjPIa+rIqePvmMvD6Ja8vhUdPj2CKZsQlDuRYjzrY3GeLzM2fKbReq Dsgfau8FGbCAoqh4mAdzU4dtmGg+eOuIPtYBYACRJiwA6SjQmw4Lq/NxSDxB8RXx5G3L9nqA H+4kLEz5Tml8v+5g7X1mfV4ZgTsNz9yuFbDMjJrsQOMD3jhiuheYwkcbyfuzIepv2p9T8R4Z bxiiZlG/42x2Laf2mzrxeo8w780Aw243un8lOciWuLm72zeBsKT+56wa5JeBrQ7EQt+Ptm1r hQ4m6fv51LSTvdgSXU/bHzJlJXv3vxhUBnvf8YjnRZX4dbQqRWt5Yj8ERcF4pFND7m6bogDP JlAKjnlbZrmGuhHjXkV1RUsZiRtixZJGbAfqFCgL3V79FupgE686NCr/Zv2Evp9/oGOtF5Dq r/Q/1VfBwndL5gUUtHPpZ1fSKAMB2Fffv9ChPhHb3ZLtByB5vske+83Fxn3pDmRHQ3pKFC7q gpFmko7VIPRw==
  • Ironport-sdr: KlRtiMKY5cso7l0MHzs8szn2l2JVCYyOrXieB59tck8ytrHSlbWQswemxurKBxglDUo6Jv2ZRI sZqYA5l5pPvCNsMUwm9FQRKk2mJt20OmWOLJmcxmCi7mjdHrbSqPjhTnaOizjCvZ8co8zTftlK cUaFDB0KD1yyt0hg8yxL+pjguWKciD5U75bTNPubNw+d+Vyr176nDlJ9uVKYO7A3U5dpNPtNEJ hFZpMVax3OxMlirvx0KV7yGUTaO3CCg5XORvieHaZ0kZmR/+MilfbtTI8X8YMkDVjDEgYuvats J6+3fW1IKSGmK5p+gw39CCko
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Sep 13, 2021 at 05:07:54PM +0200, Jan Beulich wrote:
> On 13.09.2021 16:33, Roger Pau Monné wrote:
> > On Mon, Sep 13, 2021 at 04:05:15PM +0200, Jan Beulich wrote:
> >> On 13.09.2021 15:37, Roger Pau Monné wrote:
> >>> On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote:
> >>>> 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.
> >>
> >> Oh, good, thanks for trying this out.
> >>
> >>>> --- 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.
> >>
> >> The question of whether to record tool chain capabilities in .config
> >> is still pending. I'm not convinced this is a good idea, Andrew keeps
> >> shouting me out for that, and an actual discussion doesn't really
> >> happen. Yet unlike back at the time when I first raised my concern,
> >> Anthony meanwhile supports me in at least the question (to Andrew) of
> >> when such a discussion would have happened: Neither of us is aware,
> >> yet Andrew claims it did happen, but so far didn't point out where
> >> one could read about what was discussed and decided there.
> >>
> >> For the few uses we've accumulated I gave (if at all) an ack for
> >> things happening under some sort of pressure, with the request that
> >> aformentioned discussion would happen subsequently (and, depending on
> >> outcome, these would be converted to another approach if need be). I
> >> have meanwhile realized that it was a mistake to allow such things in
> >> on this basis - the more of them we gain, the more I'm hearing "we've
> >> already got some".
> > 
> > I see, that's not an ideal situation from a review PoV, as we don't
> > have a clear placement for those and that will just cause confusion
> > (and more work since there are potentially two places to check).
> > 
> > What's the benefit of placing the checks in Kconfig instead of the
> > Makefiles?
> > 
> > As I understand Kconfig is run only once, while the Makefile could run
> > the check multiple times.
> 
> Right - as many times as a directory would be entered for building,
> times the number of evaluations of a respective variable.
> 
> > The downfall of having them in .config is that .config could suddenly
> > change as tools are updated or as it's moved around different systems
> > (yet .config already contains specific compiler version information).
> 
> Correct: Tool chain specific information may get updated, but then
> further options may get silently turned off. Plus to update tool
> chain specific information there needs to be a trigger to invoke
> kconfig in the first place. Merely relying on make dependencies is
> not enough there. Iirc we don't have any means in place yet to
> actually enforce this even when there's no other reason to run
> kconfig in the course of re-building a previously built tree.

Indeed, we would need something to trigger the (re)evaluation of
Kconfig options on every run, regardless of whether they have been
set, unless there's already some magic for options using cc-option or
shell test macros that does it. Linux will surely have the same
problem with this, and they recommend to use Kconfig to check for
compiler capabilities [0].

My opinion would be to go for Kconfig because it's IMO cleaner to
represent the options there rather than mixed into Makefiles, and
should also prove to be faster regarding build times due to the single
evaluation. We can always bring the environment related issues to the
Kconfig developers in order to try to find a solution for it.

Thanks, Roger.

[0] 
https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#adding-features-that-need-compiler-support



 


Rackspace

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