[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090819013124.7539E4730F@magilla.sf.frob.com>
Date: Tue, 18 Aug 2009 18:31:24 -0700 (PDT)
From: Roland McGrath <roland@...hat.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Rusty Russell <rusty@...tcorp.com.au>,
Helge Deller <deller@....de>,
linux-parisc <linux-parisc@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: kernel segv with 2.6.31-rc6 ?
> Actually, I think we do; the module loader is a runtime linker, after
> all. [...]
Indeed you do. I've just read some of the parts of ld that normally
address this issue for HPPA. They don't run for ld -r. So this is just
another fine example of the lunacy of the ET_REL .ko madness that would be
naturally avoided by a sensible tweaked ET_DYN scheme. But that battle was
lost way, way back in the long, long ago, so long ago they were probably
even still making HPPA machines then.
> 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.
Not with ld -r as it is today. That's what ld does for you in proper final
links. It looks to me like you might be able to enable some special mode
("finalish link" for -r) with a hack to HPPA ld to apply this stub-creation
logic based on the assumption that the symbols in the relocs will be
resolved to themselves, and barf on you if they're used for SHN_UNDEF symbols.
But nobody cares enough to fiddle with ld.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists