>>>>> "WLI" == William Lee Irwin <wli@holomorphy.com> writes: WLI> On Thu, Jan 10, 2002 at 10:20:24AM +0200, Momchil Velikov wrote: >> FUD or just plain stupid. He could have solved all the problems he >> described by just simply linking statically his proggie. WLI> Well, yes, though there may be some reason it must be dynamically linked. WLI> "Marvin" == Marvin Justice <mjustice@austin.rr.com> writes: >>> Anyway, I just wanted to let you know that there are some glibc issues that >>> are more restrictive than the kernel issues. Actually, these aren't Marvin's words. WLI> On Thu, Jan 10, 2002 at 10:20:24AM +0200, Momchil Velikov wrote: >> FUD. Period. On my system mozilla's (as an example of shlib heavy app) >> shared libraries occupy (with holes) 0x40000000-0x417bc000 == >> 0x17bc000 == 24887296 ~= 23.7 MB. What's the problem allocating >> libraries at e.g. 0x8000000? Or 0xa0000000? WLI> Actually, it's an interaction with the kernel. The ELF .interp is loaded WLI> by default at 0x40000000 when formatted as a DSO. Formatting the .interp How come ? The kernel just searches for mmap space starting at TASK_UNMAPPED_BASE == TASK_SIZE / 3. It manages the [TASK_UNMAPPED_BASE, TASK_SIZE) range by a simple address ordered first fit algorithm. It just doesn't leave enough space for sbrk, _for no good reason_. (at least as far as I can tell). Here's the program headers of /lib/ld-2.2.4.so LOAD 0x000000 0x00000000 0x00000000 0x13ce0 0x13ce0 R E 0x1000 LOAD 0x013ce0 0x00014ce0 0x00014ce0 0x002f8 0x006f8 RW 0x1000 DYNAMIC 0x013d98 0x00014d98 0x00014d98 0x000b0 0x000b0 RW 0x4 I don't see 0x40000000 here. WLI> as a statically linked executable will allow you to specify the placement WLI> in memory (at least in an advisory way) of your runtime linker, if you WLI> care to implement a runtime linker or adjust glibc's. Alternatively, you WLI> could have the .interp literally copy itself out of the way and perform WLI> relocation processing on itself a second time. WLI> At any rate, probably the core issues here are (as I see them) WLI> (1) glibc's allocator is unable to deal with a process address space WLI> fragmented by ld.so sitting up at 0x40000000 Indeed, Doug Lea's malloc slightly predates most mmap based OSes. However, moving TASK_UNAMPPED_BASE up will solve the problem with most (non mmap) using programs. The mmap using programs, use mmap anyway (surprise ;) and are perfectly capable of more inteligent mmaping, e.g. by specifying a hint as a first parameter to mmap. The kernel will obey this hint. WLI> (2) the kernel makes a default placement decision for the .interp that WLI> fragments the process address space Not for interp but for any mmap (NULL, ...). Regards, -velco -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
