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

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 05/07/2022 17:03, Jan Beulich wrote:
> 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.
Sorry, I haven't looked at this patch because I am not very familiar 
with the Makefile code. Reading through the commit message, I think 
having this patch would be quite beneficial.
Regarding the review, Anthony has been working on the build system 
recently. So maybe he could give a review? (I have CCed him).
Cheers,

--
Julien Grall