RE: [PATCH] EFI: strip xen.efi when putting it on the EFI partition

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi Jan,

> -----Original Message-----
> Subject: Re: [PATCH] EFI: strip xen.efi when putting it on the EFI partition
> 
> On 09.06.2022 17:52, 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.
> 
> Without any feedback / ack I guess I'll consider this of no interest
> (despite having heard otherwise, triggering me to put together the
> patch in the first place), and put on the pile of effectively
> rejected patches.

I did a test for this patch on my x86 machine and I think this patch is
doing the correct thing, so:

Tested-by: Henry Wang <Henry.Wang@xxxxxxx>

I also noticed that Julien is suggesting maybe we can have Anthony as
the reviewer for this patch, so I also add him in the CC of this email.

Kind regards,
Henry

> 
> Jan