kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
thiago at kde.org
Tue Aug 16 12:17:17 BST 2011
On Tuesday, 16 de August de 2011 12:50:47 Laszlo Papp wrote:
> > 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
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
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
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...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel