[Trac #639] Not using prelink(1)

Zarro Boogs per Child bugtracker at laptop.org
Sun Mar 25 12:11:51 EDT 2007


#639: Not using prelink(1)
-------------------------+--------------------------------------------------
 Reporter:  ajax         |        Owner:  cjb    
     Type:  enhancement  |       Status:  new    
 Priority:  normal       |    Milestone:  BTest-3
Component:  performance  |   Resolution:         
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by AlbertCahalan):

 I'm fairly sure that people are slightly wrong about Ubuntu Feisty.

 Ubuntu Feisty is now using DT_GNU_HASH. Fedora Core 6 was the first to use
 this. It makes run-time linking go faster for apps that use long and
 highly redundant symbol names. C++ apps are often this way, particularly
 when using Boost. For example, on a Boost-infected project at work I saw
 symbol names that were 1.5 KB long. No kidding. When ELF was originally
 designed, it was quite logically assumed that nobody would do such a
 thing. The older ELF hash function was designed to handle names chosen by
 programmers, which worked great for Pascal, C, FORTRAN, etc.

 Prelink thus makes much less of a difference. Run-time linking still isn't
 free though. The time has not been driven to zero, so prelink can still be
 useful.

 There are two other issues though, one one against and one in favor.

 We like address space randomization for security. Prelinking defeats this.
 BTW, you need to build executables with -fPIE to get the full benefit of
 address space randomization, and you really should randomize the vdso
 independently of the stack.

 Pre-linking saves memory. Sharing pages isn't possible if they get
 modified differently by ld.so, and not currently done if they get modified
 at all. On a pre-linked system, more of your library pages can share
 memory. It even becomes possible (not implemented) to share some page
 tables.

-- 
Ticket URL: <http://dev.laptop.org/ticket/639#comment:5>
One Laptop Per Child <http://laptop.org/>



More information about the Bugs mailing list