On 07.11.2024 13:17, Andrew Cooper wrote: > On 07/11/2024 11:57 am, Jan Beulich wrote: >> On 07.11.2024 12:30, Andrew Cooper wrote: >>> On 07/11/2024 9:48 am, Jan Beulich wrote: >>>> On 07.11.2024 10:40, Roger Pau Monné wrote: >>>>> On Thu, Nov 07, 2024 at 09:21:26AM +0000, Andrew Cooper wrote: >>>>>> On 07/11/2024 8:49 am, Roger Pau Monne wrote: >>>>>>> The tools infrastructure used to build livepatches for Xen >>>>>>> (livepatch-build-tools) consumes some DWARF debug information present in >>>>>>> xen-syms to generate a livepatch (see livepatch-build script usage of >>>>>>> readelf >>>>>>> -wi). >>>>>>> >>>>>>> The current Kconfig defaults however will enable LIVEPATCH without >>>>>>> DEBUG_INFO >>>>>>> on release builds, thus providing a default Kconfig selection that's not >>>>>>> suitable for livepatch-build-tools even when LIVEPATCH support is >>>>>>> enabled, >>>>>>> because it's missing the DWARF debug section. >>>>>>> >>>>>>> Fix by forcing the selection of DEBUG_INFO from LIVEPATCH. >>>>>>> >>>>>>> Signed-off-by: Roger Pau Monné <[email protected]> >>>>>> Oops, yes. >>>>>> >>>>>> Reviewed-by: Andrew Cooper <[email protected]> >>>>>> >>>>>> Fixes tag ? >>>>> Was borderline on adding one, but wasn't sure since it's strictly >>>>> livepatch-build-tools that requires the DWARF data, but custom made >>>>> livepatches (like the examples in tests) do not require such >>>>> information. >>> Ok. I guess it doesn't matter too much. >>> >>>> At which point: Is "select" really appropriate then? Wouldn't it be more >>>> logical then to change DEBUG_INFO's default to take LIVEPATCH into account >>>> (still permitting people to turn debug info off if they know they won't >>>> need it)? >>> I am very disinterested in letting people who think they can do >>> livepatching without debug symbols shoot themselves in the foot like that. >>> >>> It's only debugging symbols. If people *really* think they know >>> better, they can strip them themselves. >> Besides my abstract concern, let me also add a concrete practical one. I'm >> sure you've noticed that xen.efi is _much_ slower to link with debug info >> than without, or than xen-syms. That's a consequence of how GNU ld (really: >> libbfd) works internally. By not allowing DEBUG_INFO to stay off you're >> forcing me to either wait longer for every single one of my post-commit >> pre-push build tests, or to turn off LIVEPATCH there. The latter not really >> being a good idea. >> >> Nevertheless, as said in reply to Roger: Go ahead if you absolutely think >> that's the only sensible way. > > I had noticed that link was taking a long time. I hadn't realised it > was this specifically. > > But to put this another way, you're arguing to intentionally avoid > fixing a sharp corner, because there's a perf issue in Binutils.
I understand there is a sharp corner, yet recall I had suggested an alternative. People changing defaults are responsible for what they're doing, after all. > I will note that it was you who forced the generation of xen.efi on > everyone, even those who didn't want it, without any knob to turn it off. True, but if there's desire to turn it off, a knob can always be added. EFI support pre-dates the introduction of Kconfig by several years, iirc. Jan
