[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 07.07.2022 13:58, Wei Chen wrote: > Hi Jan, > > On 2022/7/6 13:44, Henry Wang wrote: >> 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> >> > > Because there was no Arm EFI environment in hand at the time, Henry only > tested the x86 part.I have setup an Arm platform with UEFI v2.70 (EDK > II, 0x00010000) today, and this patch works well when boot Xen as an EFI > application from UEFI shell. > > But the binaries sizes are the same with/without this patch. Is it expected? > I have enabled: > CONFIG_DEBUG=y > CONFIG_DEBUG_INFO=y Well, the way "xen" is built (and "xen.efi" only being an alias thereof), debug info is stripped in the course. That's quite different from x86, where - with a new enough linker - debug info is retained while linking (and it is truly linking by which xen.efi is built), and hence can make sense to strip while installing. > Is there anything I should be aware to test this patch? > > -rwxrwxr-x 1 weic weic 1081504 Jul 7 18:43 xen > -rwxrwxr-x 1 weic weic 1081504 Jul 7 19:43 xen > > Tested-by (Arm only): Wei Chen <Wei.Chen@xxxxxxx> Thanks. Btw the proper form of the tag, as of a couple of months ago, is Tested-by: Wei Chen <Wei.Chen@xxxxxxx> # arm Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |