Re: kernel segv with 2.6.31-rc6 ?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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