From: Hannah S. <ha...@sc...> - 2005-08-01 16:49:18
|
Hello! Just a note from a non-regular participant here. On Mon, Aug 01, 2005 at 11:53:31AM -0400, James Y Knight wrote: >[...] >It's having compatibility problems because it is one of the only >programs in existence that requires an mmap at a fixed offset to >succeed. Normal applications either have fixed areas in ELF sections >(and thus the linker will work around them when loading dynamic >libraries) or only load relocatable data with mmap. >It's not obvious the reason why it's crashing because it supplies >MAP_FIXED to mmap, which, under linux means "ignore any mappings I'm >blasting over and map it anyways". Oh *rolls eyes*. Under OpenBSD it's MAP_FIXED Do not permit the system to select a different address than the one specified. If the specified address cannot be used, mmap will fail. If MAP_FIXED is specified, addr must be a multiple of the pagesize. Use of this option is discouraged. The error code will be ENOMEM. >Supplied patch fixes that, so at >least it'll fail with an error instead of dying ungracefully. Linux >will always map at the supplied address unless there is something >there already when MAP_FIXED is not supplied. >I believe either of the following solutions would work: >1) Be able to handle relocating its core file. >2) Mark the sections of memory the core file must load into as >reserved in an ELF section in the sbcl binary. >Option 1 would be the best. Obviously it'll be slower to relocate >than not to, so base addresses that will work for most systems >without relocation would still be a good idea. However, at least, >then, it will work for sure everywhere. OTOH, relocation needs non-shared writable mappings to change the addresses. I.e. the core files will not be shared in memory between multiple instances of sbcl, which would be unfortunate. A way to fix this would be having the core itself be position independent, and linkage tables (which would need to be relocated) would be separate regions, so only they need non-shared writable mappings. I.e. similar things as they're done for usual shared libraries. >Option 2 would probably be easier, however. Just a simple matter of a >linker script and not calling os_validate upon startup (because the >regions are already mapped). Would also want to unmap the extra >memory that the particular core file didn't end up using, as well, >since the binary has to reserve the maximum any core file *could* >use. 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. I'm not sure whether reserved sections are supported by OpenBSD's ELF loader (are you sure they are on Linux). Do you mean sections of a type like .bss? That should be possible, using assembler code like this: .global y .section .bss2, "aw", @nobits y: .skip 16384 You could probably force the section to have a certain base address using a custom linker script, and voilà. Using the label (y in the example), you can check at startup time whether the address matches the expected map address of your core. Then you munmap() that section immediately before mapping the core with MAP_FIXED and the needed base address. >I don't have the knowhow to do either. Arjan would probably know how >to do the linker magic in #2. >[...] Kind regards, Hannah. |