From: Dave R. <ld...@dr...> - 2005-08-01 20:58:37
|
Thanks, James. Just some questions to further my own knowledge... On Mon, 2005-08-01 at 11:53 -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. 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) ?? > 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". 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. 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. > 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. Is there any way to actually get the loader to do this for us? I'm thinking about a dump algorithm that links the core file with an SBCL runtime and creates an ELF. That way, not only is the memory region reserved in the ELF, the data is actually present there, too. Since SBCL carries its tag bits in the lower bits of an address, they should be transparent to the loader, no? I'm not an ELF expert by any means, so this may be a stupid idea. > 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. 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? -- Dave Roberts <ld...@dr...> |