[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] x86/build: use --orphan-handling linker option if available
On Mon, Mar 07, 2022 at 02:53:32PM +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> LGTM, just two questions. > --- > v2: Don't use (NOLOAD) for ELF; it has undocumented (and unhelpful) > behavior with GNU ld there. Also place .{sym,str,shstr}tab for LLVM > ld. > --- > 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. > > --- 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 > + > $(TARGET): TMP = $(@D)/.$(@F).elf32 > $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32 > $(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) > $(XEN_IMG_OFFSET) \ > @@ -146,7 +148,7 @@ $(TARGET)-syms: $(BASEDIR)/prelink.o $(o > >$(@D)/.$(@F).1.S > $(MAKE) $(build)=$(@D) $(@D)/.$(@F).1.o > $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \ > - $(@D)/.$(@F).1.o -o $@ > + $(orphan-handling-y) $(@D)/.$(@F).1.o -o $@ > $(NM) -pa --format=sysv $(@D)/$(@F) \ > | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv > --sort \ > >$(@D)/$(@F).map > @@ -220,7 +222,7 @@ endif > | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort > >$(@D)/.$(@F).1s.S > $(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o > $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds -N $< \ > - $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(note_file_option) > -o $@ > + $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(orphan-handling-y) > $(note_file_option) -o $@ > $(NM) -pa --format=sysv $(@D)/$(@F) \ > | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv > --sort >$(@D)/$(@F).map > rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]* > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -12,6 +12,13 @@ > #undef __XEN_VIRT_START > #define __XEN_VIRT_START __image_base__ > #define DECL_SECTION(x) x : > +/* > + * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld > + * for PE output, in order to record that we'd prefer these sections to not > + * be loaded into memory. > + */ > +#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) } > +#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) } > > ENTRY(efi_start) > > @@ -19,6 +26,8 @@ ENTRY(efi_start) > > #define FORMAT "elf64-x86-64" > #define DECL_SECTION(x) #x : AT(ADDR(#x) - __XEN_VIRT_START) > +#define DECL_DEBUG(x, a) #x 0 : { *(x) } > +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) } Would it be helpful to place those in a > > ENTRY(start_pa) > > @@ -179,6 +188,13 @@ SECTIONS > #endif > #endif > > +#ifndef EFI > + /* Retain these just for the purpose of possible analysis tools. */ > + DECL_SECTION(.note) { > + *(.note.*) > + } PHDR(note) PHDR(text) Wouldn't it be enough to place it in the note program header? The buildid note is already placed in .rodata, so any remaining notes don't need to be in a LOAD section? > +#endif > + > _erodata = .; > > . = ALIGN(SECTION_ALIGN); > @@ -266,6 +282,32 @@ SECTIONS > __ctors_end = .; > } PHDR(text) > > +#ifndef EFI > + /* > + * With --orphan-sections=warn (or =error) we need to handle certain linker > + * generated sections. These are all expected to be empty; respective > + * ASSERT()s can be found towards the end of this file. > + */ > + DECL_SECTION(.got) { > + *(.got) > + } PHDR(text) > + DECL_SECTION(.got.plt) { > + *(.got.plt) > + } PHDR(text) > + DECL_SECTION(.igot.plt) { > + *(.igot.plt) > + } PHDR(text) > + DECL_SECTION(.iplt) { > + *(.iplt) > + } PHDR(text) > + DECL_SECTION(.plt) { > + *(.plt) > + } PHDR(text) > + DECL_SECTION(.rela) { > + *(.rela.*) > + } PHDR(text) Why do you need to explicitly place those in the text program header? Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |