> Thanks. The kernel is now attempting to load the modules. It's now > revealed another situation in that when krtld resolves the references in > the driver the displacements are > 2GB. By default, gcc will use > relative instructions to do calls and get the addresses of external > references. However, these will only work when the displacement is +/- > 2GB. This is fine for apps that have shared libraries which can be > mapped anywhere in the address space so that limit is never encountered > but for the kernel and its device drivers this is not the case. > > I'm looking to add an architectural option to gcc to cause it to > generate instructions that will use a literal pool instead. This will be > less efficient but will support the entire 64-bit address space. > > The other option, of course, is to rework the map of the kernel address > space so that instead of starting at 0x30000000000 the device drivers > can start at somewhere in the 1GB-2GB range. > > Neale
It is relatively easy to control such mappings (we do similar things on SPARC): kobj_vmem_init() just has to set up the arenas appropriately and then all of the module text and data will come from predefined regions of the address space as determined by the arenas. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
