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

[Alexander Neundorf]

On Tuesday 16 August 2011, Thiago Macieira wrote:
...
> 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.

...not sure which email to reply too, so I just use this one.

Maybe I didn't express clearly what I wanted to say, or I misunderstood Dirk, 
or Dirk was wrong.

So, I try again, just to make sure there are no misunderstandings.

Right now, for kdeinit-apps, we create a "kdeinit module" or plugin, which 
contains the actual application code, and additionally a tiny executable which 
loads this plugin and so runs the application.

Beside that, we run a kdeinit instance, which can dlopen these plugins, and 
start the applications they contain.
By doing this we save memory and time e.g. for relocations.

The idea here was not to get rid of this mechanism completely.
If I understood correctly, with a PIE executable it is possible to dlopen the 
executable and call a symbol from it.
This would make it possible to simply create regular-looking, standalone 
executables instead of the combination of plugin+tiny executable, and at the 
same time keep the kdeinit instance around, which would then not dlopen the 
plugin, but dlopen the PIE executable, and call the symbol from the PIE 
executable instead of from the plugin, this way providing the same benefits as 
we have now.

I.e. keep the mechanism, but without the necessity to split the executable 
into plugin+loader executable.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110816/05292ee0/attachment.html>