From: James Y K. <fo...@fu...> - 2005-08-02 15:12:15
|
On Aug 1, 2005, at 4:58 PM, Dave Roberts wrote: > Thanks, James. Just some questions to further my own knowledge... > > [...] > > And it uses fixed mmap offsets because it has to load its core file > into > the same address space in which the core was originally created (to > preserve all the pointer relationships therein) ?? Right. > It seems like it should be at least printing a quick "mmap" when it > fails this way in os_validate, which I don't see in the failing > output. > See the context lines at the end of your patch, in fact. It must be > failing some other place. Not sure where since the same basic code > exists in os_map in src/runtime/linux-os.c. With the current code the mmap is _succeeding_. It just happens to have overwritten some random bits of some other library with zeros. Needless to say the other library doesn't work too well after that. >> This will work as long as there is nothing _else_ on the system >> that is unrelocatable and wants to go where the reserved bits of >> memory are. > > Well, unrelocatable and a shared file, no? We'll never conflict > with an > unrelocatable statically linked binary, right? And aren't all DSOs > relocatable by definition? I believe it is possible to make an unrelocatable shared library...but of course probably nobody _has_ one of those. But what I really meant was, various bits of (unrelocatable) memory have been reserved for a variety of reasons and cannot be used. Space for the kernel, dynamic loader, etc. Their locations, size, and even existence have changed in the past and who's to say they won't change again. However, if you keep away from the edges of address space it's usually safe, so I think this isn't likely to be an problem in practice. James |