On Tue, 2009-08-18 at 17:14 -0700, Roland McGrath wrote: > > Actually, for parisc, its not reasonable. It's expected that our modules > > have multiple text sections (we have to use -ffunction-sections to > > generate them in order that the PCREL17 jump stubs can be interleaved). > > I don't think you need what you think you need. Having lots of sections in > your .o's when you compile is fine. These should be combined by the linker > script that creates the .ko, however. Unless I am missing something, there > is no purpose to this section distinction at insmod time--it's only > important for the relative layout of the parts of the .ko's text, which > winds up contiguous whether laid out that way at ld -r (.ko creation) time > or at insmod time. Actually, I think we do; the module loader is a runtime linker, after all. We have specific module bugs we fixed by inserting relocation stubs between the text sections. Our specific problem is that the standard pa relocation is PCREL17 ... as you can appreciate, 17 bits of relative jump isn't a lot. If the target isn't within the 17 bits, we have to insert a relocation stub to do an indirect absolute jump thought the GOT. Our problems occur when a text section is wider than the 17 bits, which happens a lot in the larger modules ... with nowhere to put the stub within range of the relocation we can't load them. Our fix is to split the text sections with -ffunction-sections so we can be pretty much assured of having a stub location within the 17 bits. We don't care what they're called or anything. We just care that the .text is split up into multiple separately relocateable sections so we can get the stubs within range of the jumps. Now, of course, if the final linker could be persuaded to sprinkle needed stubs through the text section and all we have to do is GOT relocations, we don't need all the jiggery-pokery ... but I'm told this can't be done. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
