* Trent W. Buck | 2009-03-25 20:10:22 [+1100]: >On Wed, Mar 25, 2009 at 09:29:56AM +0100, Sebastian Andrzej Siewior wrote: >> >+ CFLAGS="-fPIC" ./waf --nocache configure --prefix=/usr >> this is not cool because now -fPIC is also used for midori binary >> itself. > >Please help me to understand why it's bad to use -fPIC for the binary >itself. It will work, but with unneeded overhead. Let me explain a little: -fPIC generates position independent code. That is required for .so files because they are loaded at "random position" in memory while the binary is always loaded always at the same / fixed position in memory. Now, if your code is at a random place in memory you can't rely on constant offsets to access a variable in memory. So how to solve this? You need a reference point. This is how the ABI of x86_64 solves this:
|--- test_gcc.S 2009-03-25 20:33:23.000000000 +0100 |+++ test_fPIC_gcc.S 2009-03-25 20:33:23.000000000 +0100 |@@ -8,10 +8,10 @@ | .type main, @function | main: | .LFB20: |+ leaq .LC0(%rip), %rdi | subq $8, %rsp | .LCFI0: |- movl $.LC0, %edi |- call puts |+ call p...@plt | xorl %eax, %eax | addq $8, %rsp | ret $.LC0 is the variable I'm going to pass to puts as an argument. Without -fPIC it is just moved (movl) into the register and then we jump to puts. With -fPIC an constant (.LC0) is added to $rip (the current instruction pointer) and saved in the argument register. leaq is little more complex and has two bytes more in the binary level. So your variable here is reference relative from your current position. This little overhead has to be done for all variables (except for those on stack) and for a "few" branches. Does not look that bad, does it? Now let see what x86_32 does: |--- test_i386.S 2009-03-25 20:37:40.000000000 +0100 |+++ test_fPIC_i386.S 2009-03-25 20:37:46.000000000 +0100 |@@ -12,16 +12,28 @@ | pushl -4(%ecx) | pushl %ebp | movl %esp, %ebp |- pushl %ecx |- subl $4, %esp |- movl $.LC0, (%esp) |- call puts |- addl $4, %esp |+ subl $24, %esp |+ movl %ebx, -4(%ebp) |+ call __i686.get_pc_thunk.bx |+ addl $_GLOBAL_OFFSET_TABLE_, %ebx |+ movl %ecx, -8(%ebp) |+ leal ....@gotoff(%ebx), %eax |+ movl %eax, (%esp) |+ call p...@plt |+ movl -8(%ebp), %ecx | xorl %eax, %eax |- popl %ecx |+ movl -4(%ebp), %ebx |+ movl %ebp, %esp | popl %ebp | leal -4(%ecx), %esp | ret Again, without -fPIC $.LC0 is pushed directly on stack but with there is little more going going on. save ebx, get a pointer, add GOT offset, load .LCO via an offset the GOT table and then push on stack and restore ebx later. I could add more arches here, compare them and their overhead but I think you get the point. >> So I guess that you should be fine if you take my initial patch and >> replace pariss with parisc* > >Will that still result in -fPIC being used for the binary -- but only >on HPPA? no, just libkatze and a few others but not the midori binary and yes just on hppa. >PS: as you noticed, for the experimental upload just now I just set >PIC unconditionally. From Debian Policy, -fPIC should *always* be >used for .so files. So as I see it the remaining issue is to ensure >that -fPIC isn't used or the midori binary, but is used for the .so >files. the "unconditionally" in my patch title was meant for the .a files not the whole build process. My bad wording + after changing the code I did not change the subject. As I wrote in my other email, I try to now to build libkatze twice: once with -fPIC to link against .so files and once without to link against the midori binary. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
