|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] EFI: strip xen.efi when putting it on the EFI partition
On Thu, Jun 09, 2022 at 05:52:45PM +0200, Jan Beulich wrote:
> With debug info retained, xen.efi can be quite large. Unlike for xen.gz
> there's no intermediate step (mkelf32 there) involved which would strip
> debug info kind of as a side effect. While the installing of xen.efi on
> the EFI partition is an optional step (intended to be a courtesy to the
> developer), adjust it also for the purpose of documenting what distros
> would be expected to do during boot loader configuration (which is what
> would normally put xen.efi into the EFI partition).
>
> Model the control over stripping after Linux'es module installation,
> except that the stripped executable is constructed in the build area
> instead of in the destination location. This is to conserve on space
> used there - EFI partitions tend to be only a few hundred Mb in size.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> GNU strip 2.38 appears to have issues when acting on a PE binary:
> - file name symbols are also stripped; while there is a separate
> --keep-file-symbols option (which I would have thought to be on by
> default anyway), its use so far makes no difference,
> - the string table grows in size, when one would expect it to retain its
> size (or shrink),
> - linker version is changed in and timestamp zapped from the header.
> Older GNU strip (observed with 2.35.1) doesn't work at all ("Data
> Directory size (1c) exceeds space left in section (8)").
>
> Future GNU strip is going to honor --keep-file-symbols (and will also
> have the other issues fixed). Question is whether we should use that
> option (for the symbol table as a whole to make sense), or whether
> instead we should (by default) strip the symbol table as well.
I guess trying to keep those symbol might be useful, if it's not too
big, to help debugging system in production.
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -465,6 +465,22 @@ endif
> .PHONY: _build
> _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>
> +# Strip
> +#
> +# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
> +# is installed. If INSTALL_EFI_STRIP is '1', then the default option
> +# --strip-debug will be used. Otherwise, INSTALL_EFI_STRIP value will be used
> +# as the option(s) to the strip command.
It would be useful to also document INSTALL_EFI_STRIP in ./INSTALL or in
./docs/misc/efi.pandoc (efi.pandoc is where EFI_VENDOR is documented for
example, so probably a better place for the doc of the new option).
> +ifdef INSTALL_EFI_STRIP
> +
> +ifeq ($(INSTALL_EFI_STRIP),1)
> +efi-strip-opt := --strip-debug
> +else
> +efi-strip-opt := $(INSTALL_EFI_STRIP)
> +endif
> +
> +endif
> +
> .PHONY: _install
> _install: D=$(DESTDIR)
> _install: T=$(notdir $(TARGET))
> @@ -489,6 +505,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
> ln -sf $(T)-$(XEN_FULLVERSION).efi
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
> ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
> if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
> + $(if $(efi-strip-opt), \
> + $(STRIP) $(efi-strip-opt) -p -o
> $(TARGET).efi.stripped $(TARGET).efi && \
> + $(INSTALL_DATA) $(TARGET).efi.stripped
> $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
This optional part of the script that ends with "||" means that if
`strip` or `install` fails, we would install the non stripped binary. Is
this something that's acceptable? (Plus of doing that is avoiding
changing the next line, and avoiding a longer $(if ,).
> $(INSTALL_DATA) $(TARGET).efi
> $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
> elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) &&
> pwd)/%,%,$(D))" ]; then \
> echo 'EFI installation only partially done (EFI_VENDOR
> not set)' >&2; \
An other thing, the "*.efi.stripped" file is I think going to be left
over and not removed during `make clean`.
Cheers,
--
Anthony PERARD
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |