Skip to contentSkip to conversation

64 bit kernel and module dp values again

parisc-linux Alan Modra 2 participants 2 messages Apr 4, 2001 – Apr 6, 2001 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alan Modra

author
#1 lore raw
Quoted 7 lines · Richard Hirst
Quoted 6 lines · Richard Hirst

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...

Quoted 4 lines

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.

Quoted 8 lines
	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

Signature · 1 line
Linuxcare
#2 lore raw
Quoted 7 lines · Alan Modra
Quoted 5 lines · Richard Hirst
Quoted 4 lines · Richard Hirst

Hi Alan,
Code from drivers/block/loop.o, built as a 64 bit module, using
xc-20010307.tgz

Quoted 5 lines
Quoted 2 lines
Quoted 2 lines

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