Re: [PATCH] xen/Kconfig: livepatch-build-tools requires debug information

[Jan Beulich <jbeulich@xxxxxxxx>]

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é <roger.pau@xxxxxxxxxx>
>>>>>> Oops, yes.
>>>>>>
>>>>>> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>>>>
>>>>>> 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