|
From: Yeshurun, M. <mei...@in...> - 2005-08-07 09:07:34
|
Hi, I've been using a PIE build of Valgrind 3.0 on a 64 bit platform. So far it's working great, and the extra virtual memory is a life saver. I have just two small questions: 1. Is it normal for a PIE build to be slower? 2. Is it normal for a PIE build to allocate a huge amount of virtual memory (270G) even when running on tiny programs? (I don't really mind, but the Linux administrators made me swear that I would ask you, so please just say yes :) Thanks, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Nicholas Nethercote Sent: Friday, August 05, 2005 6:58 PM To: Valgrind Users Subject: [Valgrind-users] Clarification about --enable-pie/--disable-pie Hi, In Valgrind 2.4.0, we built Valgrind as a position-independent executable=20 (PIE) if the toolchain supported it. This turned out to cause quite a few=20 problems -- people having random, inexplicable crashes. So for 3.0.0 we turned it off by default because it was causing too many problems. As a result of all this, it unfortunately seems like=20 --enable-pie/--disable-pie has taken on a mythical status... as though we=20 deliberately shipped a crippled Valgrind and you have to find the special=20 configure option to get it to work, bwaha! So I'm trying to clear up the confusion. Here's a summary: - 3.0.0 does not use PIE by default. This is much more stable. Do not use --enable-pie unless you have to. - Any why would you have to? Because a PIE build can give your program more address space when running under Valgrind, particularly on AMD64. - However, as we have seen, using PIE is a bit flaky and has caused problems on many systems. In short: don't use --enable-pie when configuring Valgrind unless you=20 know you need the extra address space it allows. And if you do use it,=20 don't be shocked if Valgrind crashes. We'd like to fix these problems, but we don't understand them yet. Any=20 information people can shed on them would be great, but as usual, saying "I built with PIE and Valgrind crashes!! What's wrong??" isn't very=20 helpful. The more relevant information you can provide, the better. N ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2005-08-07 09:18:20
|
> 1. Is it normal for a PIE build to be slower? At the moment ... yes. > 2. Is it normal for a PIE build to allocate a huge amount of virtual > memory (270G) even when running on tiny programs? (I don't really mind, > but the Linux administrators made me swear that I would ask you, so > please just say yes :) :-) I'm starting to think about rewriting the low level address space manager, so that all this PIE nonsense goes away once and for all (a rewrite that worked correctly would fix both these problems). J |
|
From: Christian P. <tr...@ge...> - 2005-08-07 14:55:42
|
On Sunday 07 August 2005 11:56, Julian Seward wrote: > > 1. Is it normal for a PIE build to be slower? > > At the moment ... yes. > > > 2. Is it normal for a PIE build to allocate a huge amount of virtual > > memory (270G) even when running on tiny programs? (I don't really mind, > > but the Linux administrators made me swear that I would ask you, so > > please just say yes :) > > > :-) > > I'm starting to think about rewriting the low level address space > manager, so that all this PIE nonsense goes away once and for all > (a rewrite that worked correctly would fix both these problems). Oh yes, pleeeease :-D This is gonna fix *my* problem I still seem to have as well ;) Cya, Christian Parpart. =2D-=20 16:54:48 up 137 days, 6:02, 0 users, load average: 2.52, 2.91, 3.17 |