Re: [PATCH] x86/EFI: work around GNU ld 2.36 issue

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.02.2021 11:33, Andrew Cooper wrote:
> On 05/02/2021 08:11, Jan Beulich wrote:
>> On 04.02.2021 14:38, Jan Beulich wrote:
>>> Our linker capability check fails with the recent binutils release's ld:
>>>
>>> .../check.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_info'
>>> .../check.o:(.debug_info+0x6): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_abbrev'
>>> .../check.o:(.debug_info+0xc): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_str'+76
>>> .../check.o:(.debug_info+0x11): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_str'+d
>>> .../check.o:(.debug_info+0x15): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_str'+2b
>>> .../check.o:(.debug_info+0x29): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_line'
>>> .../check.o:(.debug_info+0x30): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_str'+19
>>> .../check.o:(.debug_info+0x37): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_str'+71
>>> .../check.o:(.debug_info+0x3e): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_str'
>>> .../check.o:(.debug_info+0x45): relocation truncated to fit: R_X86_64_32 
>>> against `.debug_str'+5e
>>> .../check.o:(.debug_info+0x4c): additional relocation overflows omitted 
>>> from the output
>>>
>>> Tell the linker to strip debug info as a workaround. Oddly enough debug
>>> info has been getting stripped when linking the actual xen.efi, without
>>> me being able to tell why this would be.
>> I've changed this to
>>
>> "Tell the linker to strip debug info as a workaround. Debug info has been
>>  getting stripped already anyway when linking the actual xen.efi."
>>
>> as I noticed I did look for -S only yesterday, while we have
>>
>> EFI_LDFLAGS += --image-base=$(1) --stack=0,0 --heap=0,0 --strip-debug
> 
> So, in terms of the bugfix, Acked-by: Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>

Thanks.

> However, we ought be keeping the debug symbols for xen-syms.efi (or
> equiv) seeing as there is logic included here which isn't in the regular
> xen-syms.

Well, perhaps. Besides the 2.36 binutils regression needing fixing
(or preventing us to avoid the stripping in case that's the linker
version used), there are a few more points relevant here:

- Checking with a random older binutils (2.32) I observe the linker
  working fine, but our mkreloc utility choking on the (admittedly
  suspicious, at least at the first glance) output. This may be
  possible to deal with, but still.

- It would need checking whether the resulting binary works at all.
  All the .debug_* sections come first. Of course there are surely
  again ways to overcome this (albeit it smells like a binutils
  bug).

- While in ELF binaries the particular .debug_* sections are
  conventionally assumed to hold Dwarf debug info, no such
  assumption is true for PE executables. In particular I observe
  objdump (2.32 as well as 2.36) to merely dump the COFF symbol
  table when handed -g. Are you aware of consumers of the
  information, if we indeed kept it?

Jan