qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] Build *-user targets as PIE


From: Reimar Döffinger
Subject: Re: [Qemu-devel] [PATCH v2] Build *-user targets as PIE
Date: Thu, 3 Sep 2009 19:17:32 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, Sep 03, 2009 at 06:07:21PM +0300, Kirill A. Shutemov wrote:
> On Thu, Sep 3, 2009 at 5:38 PM, Paul Brook<address@hidden> wrote:
> >> PIE code usually is a bit slower. Approximately, 1% for i386 according to
> >> some tests. RISC architectures should be affected less, since they have
> >> more registers. On other hand we are getting rid from text relocations on
> >> i386 which make executable loading slower. So...
> >
> > I think you've got that backwards.
> > A traditional (fixed address) executable requires no load-time relocation 
> > for
> > internal references because all addresses are known at static link time. PIE
> > require the dynamic linker adjust all absolute addresses.
> 
> Usermode qemu on i386 is not a traditional executable, sicne it uses
> -Wl,-shared for linking. In result we've got an executable which looks
> like PIE, but dynamic linker have to resolve text relocations. I think
> the best way it to create a true PIE without a text relocations.

It is close to getting of topic, but since you state it, why try so hard
to avoid text relocations?
Sure, there are advantages (the biggest one is less issues with
mis-/insufficiently configured selinux I think), possibly better sharing
of pages when many instances are run and better delayed loading, but on
x86/i386 that doesn't sound like a clear advantage compared to the in
some cases quite relevant speed loss.
Also, since this patch adds --disable-pie, isn't the hack currently used
still necessary for that case?
Or is --disable-pie supposed to disable self-hosting? Then maybe the
option should be named --disable-self-hosting (and if that is indeed the
only side-effect it might be better to disable it by default)?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]