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

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

[Jan Beulich]

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.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -123,7 +123,7 @@ ifneq ($(efi-y),)
 # Check if the compiler supports the MS ABI.
 export XEN_BUILD_EFI := $(shell $(CC) $(XEN_CFLAGS) -c efi/check.c -o efi/check.o 2>/dev/null && echo y)
 # Check if the linker supports PE.
-XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o 2>/dev/null && echo y))
+XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) -mi386pep --subsystem=10 -S -o efi/check.efi efi/check.o 2>/dev/null && echo y))
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 endif
 

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

[Jan Beulich]

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

Jan

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

[Andrew Cooper]

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@citrix.com>

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.

~Andrew

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

[Jan Beulich]

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@citrix.com>

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

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

[Jan Beulich]

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@citrix.com>
> 
> 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