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 <[email protected]> > > --- > > 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 <[email protected]> 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
