[parisc-linux] Re: 64 bit kernel and module dp values again

[parisc-linux] Re: 64 bit kernel and module dp values again

[Alan Modra]

On Wed, 4 Apr 2001, Richard Hirst wrote:

> On Wed, Apr 04, 2001 at 04:32:40PM +0100, Richard Hirst wrote:
> > Hi Alan,
> >   Code from drivers/block/loop.o, built as a 64 bit module, using
> > xc-20010307.tgz
> > 
> > The stub to call $$divU is called with the kernels dp value as that is
> > what dp is left with follwing the __muldi3 call.

Sorry Richard, I should have picked up on this when I saw you exporting
millicode from the kernel yesterday.  You basically can't do it, and for
the same reason you can't export millicode from shared libs.  As you've
found, dp gets trashed...

> Having pondered on this while walking the dog (in the dry!!),
> I think I need a new stub for calling millicode that doesn't
> use dp.
> 
> 	ldil L'sym,%r1
> 	ldo  R'sym(%r1),%r1
> 	bve (r1)
> 	nop
> 
> where sym is the address of the millicode fn in the kernel.
> 
> Sound reasonable to you?

Yes.  That's the sort of thing ld would have to do too if we want to
export millicode from shared libs.

Incidentally, this problem isn't limited to 64 bit.  32 bit modules will
have the same problem, with r19 being trashed when calling kernel
millicode.

Alan "modules are evil" Modra
-- 
Linuxcare

[parisc-linux] Re: 64 bit kernel and module dp values again

[Richard Hirst]

On Thu, Apr 05, 2001 at 09:27:32AM +1000, Alan Modra wrote:
> On Wed, 4 Apr 2001, Richard Hirst wrote:
> 
> > On Wed, Apr 04, 2001 at 04:32:40PM +0100, Richard Hirst wrote:
> > > Hi Alan,
> > >   Code from drivers/block/loop.o, built as a 64 bit module, using
> > > xc-20010307.tgz
> > > 
> > > The stub to call $$divU is called with the kernels dp value as that is
> > > what dp is left with follwing the __muldi3 call.
> 
> Sorry Richard, I should have picked up on this when I saw you exporting
> millicode from the kernel yesterday.

Just for the record, I've solved this problem by reworking the stub
that modutils builds for 64 bit modules to call millicode functions
in the kernel.  The stub cannot assume dp is valid for the local module,
and must not modify dp.

If we have further problems in this area we should consider linking
each module against libgcc.a, so they each have their own local
millicode functions.

Richard