Re: [PATCH] x86/build: use --orphan-handling linker option if available

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.03.2022 12:19, Roger Pau Monné wrote:
> On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
>> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
>> binaries"), arbitrary sections appearing without our linker script
>> placing them explicitly can be a problem. Have the linker make us aware
>> of such sections, so we would know that the script needs adjusting.
>>
>> To deal with the resulting warnings:
>> - Retain .note.* explicitly for ELF, and discard all of them (except the
>>   earlier consumed .note.gnu.build-id) for PE/COFF.
>> - Have explicit statements for .got, .plt, and alike and add assertions
>>   that they're empty. No output sections will be created for these as
>>   long as they remain empty (or else the assertions would cause early
>>   failure anyway).
>> - Collect all .rela.* into a single section, with again an assertion
>>   added for the resulting section to be empty.
>> - Extend the enumerating of .debug_* to ELF. Note that for Clang adding
>>   of .debug_macinfo is necessary. Amend this by its Dwarf5 counterpart,
>>   .debug_macro, then as well (albeit more may need adding for full
>>   coverage).
>>
>> Suggested-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> I would have wanted to make this generic (by putting it in
>> xen/Makefile), but the option cannot be added to LDFLAGS, or else
>> there'll be a flood of warnings with $(LD) -r. (Besides, adding to
>> LDFLAGS would mean use of the option on every linker pass rather than
>> just the last one.)
>>
>> Retaining of .note in xen-syms is under question. Plus if we want to
>> retain all notes, the question is whether they wouldn't better go into
>> .init.rodata. But .note.gnu.build-id shouldn't move there, and when
>> notes are discontiguous all intermediate space will also be assigned to
>> the NOTE segment, thus making the contents useless for tools going just
>> by program headers.
>>
>> Newer Clang may require yet more .debug_* to be added. I've only played
>> with versions 5 and 7 so far.
>>
>> Unless we would finally drop all mentioning of Stabs sections, we may
>> want to extend to there what is done for Dwarf here (allowing the EFI
>> conditional around the section to also go away).
>>
>> See also https://sourceware.org/pipermail/binutils/2022-March/119922.html.
> 
> LLD 13.0.0 also warns about:
> 
> ld: warning: <internal>:(.symtab) is being placed in '.symtab'
> ld: warning: <internal>:(.shstrtab) is being placed in '.shstrtab'
> ld: warning: <internal>:(.strtab) is being placed in '.strtab'
> 
> So seeing your mail where you mention GNU ld not needing those, I
> think we would need to add them anyway for LLVM ld.

Hmm, that's ugly. How do I recognize LLVM ld? I can't simply use a
pre-processor conditional keying off of __clang__, as that used as the
compiler doesn't mean their ld is also in use (typically the case on
Linux). I also don't want to add these uniformly, for now knowing what
side effects their mentioning might have with GNU ld.

>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -120,6 +120,8 @@ syms-warn-dup-y := --warn-dup
>>  syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
>>  syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
>>  
>> +orphan-handling-$(call ld-option,--orphan-handling=warn) += 
>> --orphan-handling=warn
> 
> Might be better to place in xen/Kconfig with the CC checks?

Well. I've tried to stay away from complaining if people introduce
new tool chain capability checks in Kconfig. But I'm not going to
add any myself (unless things would become really inconsistent) up
and until we have actually properly discussed the upsides and
downsides of either model. Doing this via email (see the "Kconfig
vs tool chain capabilities" thread started in August 2020) has
proven to not lead anywhere. I'm really hoping that we can finally
sort this in Bukarest.

> I'm also wondering whether we could add the flag here into XEN_LDFLAGS
> and EFI_LDFLAGS, as those options are only used together with the
> linker script in the targets on the Makefile.

Not for XEN_LDFLAGS at least, and undesirable for EFI_LDFLAGS. See
the respective post-commit message remark.

>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -12,6 +12,12 @@
>>  #undef __XEN_VIRT_START
>>  #define __XEN_VIRT_START __image_base__
>>  #define DECL_SECTION(x) x :
>> +/*
>> + * Use the NOLOAD directive, despite currently ignored by ld for PE output, 
>> in
> 
> Would you mind adding GNU ld here to avoid confusion?

I've done so, but I'm not sure if implicitly you mean to say that
LLVM ld does honor the directive when linking xen.efi? If that
wasn't the case, it would rather seem misleading to have "GNU"
there. Unless e.g. LLVM ld can't link xen.efi at all ...

Jan