kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Thiago Macieira]

On Tuesday, 16 de August de 2011 12:50:47 Laszlo Papp wrote:
> Hi,
> 
> > kdeinit can be replaced by prelinking, assuming you are not a user of the
> > NVidia binary drivers. If you are, you can't prelink, so kdeinit is a
> > help:
> > 
> > /usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC shared
> > library /usr/lib/nvidia-current/libGL.so.1
> 
> The nvidia driver does a lot of tricks and libGL is not a PIC library,
> but that does not matter. My understanding was that kdeinit cannot be
> replaced by prelinking in any case since they are two different
> things.

They are different things, but in the end they are trying to solve the same 
problem: slowness at startup due to the loading of libraries and the 
processing of their relocations, plus sharing the otherwise non-sharable 
memory resulting from it.

Unfortunately, comparing the results of the best that prelink can do 
(prelinked system, libs compiled with -Wl,-z,relro) and kdeinit, done by 
launching kwrite twice from the command-line and twice using kdeinit4_wrapper, 
I still see that kdeinit produces better results.

My findings are:
1) the kdeinit executable is far larger in VSZ and just a bit larger in RSS 
(that's expected and is not a problem)

2) the kdeinit instance shares 32120 kB, whereas the non-kdeinit one shares 
28536 kB. Again, no conclusion from here (the kdeinit instance is sharing 
memory that it won't need).

3) the kdeinit instance has 10120 kB non-shared, whereas the non-kdeinit one 
has 10296 kB. If we take away the heap and stack, we get the breakdown:
	kdeinit: 88 kB code, 244 kB RO data, 376 kB RW data
  non-kdeinit: 0 kB code, 620 kB RO data, 992 kB RW data

All of the memory above is dirty, meaning in principle that it's non-sharable. 
That includes the 88 kB of code, which makes no sense at all to me. I'm 
guessing it's an effect of the prelinking, but still at loss to explain.

Also note that those RO pages, due to the way that the loader and the linker 
work, do *not* include the .rodata sections. They are only the "relro" data -- 
that is, read-only data that requires relocations.

> In harmattan the preloader is called booster, and it basically does a
> dlopen() on important libraries and we also use prelinking. They live
> together. I think prelink and kdeinit could work together, but please
> fix me. Prelink or cross-prelink could just be used by the
> distributions (but it should be done after install, just like debian
> does, prelink is setup in cron) to make it clear. :)

The booster also dlopens the plugins, I think, which further improves 
performance.

The prelinker does not properly prelink plugins, since it doesn't know what 
uses them. That means a set of applications heavily dependent on plugins, like 
the Qt- and KDE-based apps, will still not be at ideal conditions with the 
prelinker.

A workaround is to create a dummy binary or library that links to the plugins 
(violation of the definition, I know), so that the prelinker knows that it 
should work on them.

> Unfortunately I missed this session because of the football match. I
> think kdeinit is a nice thing over there. PIE executables had some
> different purpose, mostly security related. For some reason, some
> people started abusing them. There was an article by Jakub explaining
> this. I can not seem to find it right now. In any case, the main
> advantage of PIE executables was that the executable address space
> could be randomized, and ldconfig does randomize the address.
> Basically, this makes buffer-overruns more difficult. One thing is
> that ld.so ignores prelink information for PIE executables. Other than
> this I really see no point in them

Another advantage of PIE is that the executable itself is position-
independent, meaning that the code can be shared if more than one instance is 
loaded. For single-instance applications, this is not a gain.

The disadvantage of PIE is the same of any position-independent code: one 
register is reserved (big problem on a register-starved CPU like the x86), 
data accesses are indirect, via the GOT, and function calls are also indirect 
via the PLT.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110816/c6d8bc4c/attachment.sig>