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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.02.2021 12:13, Jan Beulich wrote:
> 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).

I've now convinced myself that the resulting images wouldn't work.
This can be hacked around in binutils, presumably, but the question
is whether that's worth it: A correct binary would include the
entire debug data as part of the loadable image, i.e. would require
quite a bit of memory (and time) for EFI to load. This is because
of requirements resulting from (I'm inclined to say shortcomings
in) how at least some of the PE loaders works.

On the positive side, while investigating I came across a change
(a little over a year ago) to binutils that - if working
correctly (not tried out yet) - could allow us to avoid the use of
our mkreloc tool.

> - 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?

I noticed Cygwin uses Dwarf in PE images, so there is at least a
precedent.

Jan