Re: [Qemu-devel] [PATCH v2 0/7] build-sys: Fix iscsi module loading failure

[Stefan Hajnoczi]

On Mon, Aug 25, 2014 at 10:27:07AM +0800, Fam Zheng wrote:
> On Fri, 08/22 14:35, Stefan Hajnoczi wrote:
> > Did you compare the before/after binary size with your patch?  Please
> > use size(1).
> 
> Before:
> 
> text     data     bss      dec       hex     filename
> 24264    3016     8        27288     6a98    
> /home/fam/build/master/block-iscsi.so
> 24264    3016     8        27288     6a98    
> /home/fam/build/master/block/iscsi.so
> 35356    2272     4440     42068     a454    
> /home/fam/build/master/fsdev/virtfs-proxy-helper
> 392541   7568     4672     404781    62d2d   /home/fam/build/master/qemu-ga
> 878979   33168    4204568  5116715   4e132b  /home/fam/build/master/qemu-img
> 904801   57784    4208664  5171249   4ee831  /home/fam/build/master/qemu-io
> 854255   32872    4204504  5091631   4db12f  /home/fam/build/master/qemu-nbd
> 4896094  1293960  4727496  10917550  a696ae  
> /home/fam/build/master/x86_64-softmmu/qemu-system-x86_64
> 
> After:
> 
> text     data     bss      dec       hex     filename
> 23852    2992     8        26852     68e4    
> /home/fam/build/iscsi-modules/block-iscsi.so
> 23852    2992     8        26852     68e4    
> /home/fam/build/iscsi-modules/block/iscsi.so
> 509345   32488    5192     547025    858d1   
> /home/fam/build/iscsi-modules/fsdev/virtfs-proxy-helper
> 563169   33312    5192     601673    92e49   
> /home/fam/build/iscsi-modules/qemu-ga
> 966709   58304    4204632  5229645   4fcc4d  
> /home/fam/build/iscsi-modules/qemu-img
> 940145   58088    4208792  5207025   4f73f1  
> /home/fam/build/iscsi-modules/qemu-io
> 943434   58048    4204632  5206114   4f7062  
> /home/fam/build/iscsi-modules/qemu-nbd
> 4904197  1293944  4727560  10925701  a6b685  
> /home/fam/build/iscsi-modules/x86_64-softmmu/qemu-system-x86_64

It doesn't have a big impact on the QEMU binary.  The QEMU tools do get
a bit bloated though.

I guess I'm happy with this approach.

> >
> > It's unfortunate to bloat the binary, not just from a code size
> > perspective, but also from a security perspective less code is better
> > (cannot be abused in return-oriented-programming).
> > 
> 
> So would it be a good idea to share code between executables with a
> qemu-common.so? (The same as existing modules, we also check the stamp symbol
> so that it must be built in the same source tree.)

No, I don't think there is any code size advantage to putting things in
a common shared library.  The whole library will be mmapped so it
doesn't reduce code size.

Stefan

pgpeQ7E9D2JhG.pgp
Description: PGP signature