Messages in this thread | | | Date | Tue, 15 Oct 2002 13:28:36 -0500 (CDT) | From | Kai Germaschewski <> | Subject | Re: s390x build warnings from <linux/module.h> |
| |
On Tue, 15 Oct 2002, Martin Schwidefsky wrote:
> The reason for -fpic for module code lies in the compiler. To improve the > code we use the brasl and larl instructions for function calling and > addressing data. Unluckily these two instructions have a limited range > of +-4GB. For user space programs that means that a single shared object > may not be bigger than 4GB and that no non-fpic code is linked into > shared objects. With these two restrictions we are able to generate > much better code. There is one small problem though: kernel modules. > They get loaded into the vmalloc area which is located AFTER the main > memory. A machine with more than 4 GB of main memory therefore can't > load modules anymore because the calls and references to kernel structure > can't span the distance between vmalloc area and kernel image. To get > around this problem we compile kernel modules with -fpic and make the > modutils create plt stubs and got entries. Easy ?
Makes me wonder how you deal with function pointers, where the functions are possibly in a module - guess you have to use full 64 bit there? Doesn't it possibly make sense to hack module loading to put modules into < 4 GB as well, so you can use 32bit everywhere? Oh wait, or do use stub functions at < 4 GB for function pointers as well? Well, whatever, I obviously don't know much about .got, nor S390x for that matter.
> >The next thing I do not understand is why -fpic has the effect of marking > >the section writeable, does it make .text writeable as well? And what for? > > Because -fpic code likes to relocated absolute addresses.
I still don't see why someone would want to muck with modifying .text in a shared lib, and I'm pretty sure that __ksymtab apart from the initial relocation should not need further modification, OTOH that's a moot point anyway, since gcc apparently marks it writeable and I don't see an easy way to change that.
So, as far as I'm concerned I don't really care, modify module.h as you suggested or think about mapping module memory closer to the kernel, which might be a win performance-wise anyway.
--Kai
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |