|
From: Julian S. <js...@ac...> - 2005-06-22 17:38:25
|
> > - If the user/kernel boundary is higher than expected then > > some space that could be given to the client is wasted. Your > > planned address space management changes may avoid this. > > > > - If the user/kernel boundary is higher than expected then > > valgrind may fail to load because the fixed load address > > is in kernel space. > > We've floated before the idea of building V for multiple load addresses > for the common configurations -- eg. 2GB, 3GB, 4GB. We have indeed floated that one before. However let's assume aspacemgr will get rewritten to give a more flexible address space layout. Then the actual location that V loads at isn't so critical; we can use space both above and below it. The only constraints are (1) that it doesn't intersect with the standard load place for executables (0x8048000, etc) and (2) deciding exactly where we do want V parked has a bearing on fragmentation of the address space and thus on the size of the largest contiguous block we can hand out. I don't think it's a big deal though. > I like the idea of PIE, but you're right that it is fragile. Ideally > everyone would switch over to supporting PIE now (it seems like support is > slowly increasing) and then we wouldn't have to support non-PIE systesm. PIE is a GNU-toolchain-ism. Do you really want a system which relies on it? For example, what about MacOS -- will that know about PIE ? [I don't know]. J |