|
From: Jeremy F. <je...@go...> - 2005-02-24 00:16:12
|
Julian Seward wrote: >>Mac OS X has some entertaining address space requirements and >>restrictions. >> >> > >Can you summarise what they are, so I can muse on the consequences >thereof? > > There was a description in earlier mail. I think share libraries are at a fixed, unmovable address up high, and the application is down low, so Valgrind has to sit in the middle. By the sounds of it, the superblock scheme should be able to deal with it. The magic appearing mappings are a bit problematic, but I presume that if we pad out all the Valgrind superblocks they won't get molested. >This is an amd64-linux issue. It seems that at least some >AMD64 distros (SuSE) are built using a "small model" where >offsets in literal jumps are signed 32-bits and so that appears >to force all code below 2 G. Or at least into some contiguous >2 G range. > > No, no, no, this only applies for non-PIC/PIE code. PIC/PIE code can be anywhere (and is routinely). It just requires that one object file is less that 2G, which I think we can manage. Each PIC/PIE module uses full 64-bit pointers to refer to other modules, so there are no constraints on where they are relative to each other. >Well, the work is already done - here's one I made earlier: >http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/rts/Linker.c >It works for ELF on x86, amd64, ppc32, used to work for arm, >looks like it can be made to work for ia64, and (at least at >some point in the past) could also load/link Windows PEi386 >object files :-) It's a modular linker and so can be extended >to new formats (eg COFF) by writing the appropriate COFF-parsers. > > Well, that helps, but colour me not particularly keen. >What object file format does MacOSX use? ELF? How lucky are we? > > MachO. Not much like ELF. J |