WARNING: MOD: mod_obj_relone: Illegal relocation type R_IA_64_LTOFF_TPREL22 154 (0x9a)

[Dmitry Grebenev_2]

Hi,

I am getting the following message immediately prior to "MOD: mod_obj_load: Relocation in module XXXX" error message on IA-64-based 11.22. The same DLKM compiles and loads and works fine on PA-RISC. I suspect that the problem is in accesss to the u-area. For instance, to make the reference naspp module fail, one can add something that gets the current directory. Thanks for any pointers.

[Mike Stroyan]

It looks like your compile line was missing some options specific to creating a DLKM on IA-64. The necessary options are documented in "Managing and Developing Dynamically Loadable Kernel Modules" available at
http://www.docs.hp.com./hpux/onlinedocs/dlkm-62001/dlkm-62001.html

In particular, the +kernel option will cause cc to use a R_IA_64_TPREL22 relocation instead of a R_IA_64_LTOFF_TPREL22 relocation. (The "LTOFF" part refers to a symbol lookup table that normal programs use to find symbols that may be located in shared libraries.)

[Dmitry Grebenev_2]

Thank you very much for your help. I do have the +kernel option. In fact, the very same problem happens if you take the HP's reference naspp module and add the following to its naspp_load() function:
printf("I am being loaded by pid %d\n",
u.u_procp_->p_pid) ; (of course you will need to include ). BTW, the "Developing Dynamically Loadable Kernel Modules" doc off that URL contains an error in its sample code at the very end:
it lists +XixdU option in CC_OPTS_ia64 while the compiler reports that it is only supported on PA-RISC.
Here is a full transcript (I have header in my own location - it does not change a thing):
/opt/ansic/bin/cc -c -o mod.o -Wp,-H300000 +kernel +O2 +Olit=all +DD64 -Ae +Oshortdata=0 -r -DLWSYSCALL -DPGPROF -DACLS -DAUDIT -DIDDS -D__ROSE__ -DHPONCPLUS -DVARIABLE_UAREA -DSTCP -DIVT_INTERCEPT -D_UNSUPPORTED -D_HPUX_SOURCE -D_XPG4_EXTENDED -D_KERNEL -D__STDC_EXT__ -D_CLEAN_BE -D_SYSCALL_64 -D__NO_PA_HDRS -DKERNEL_DEBUGGER -U__IA64__ -U__hp9000s800 -U__hp9000s700 -U__hppa -I. -I/mystuff/HPUX1122-64/h -I/mystuff/HPUX1122-64 naspp.c
kminstall -u naspp
config -M naspp -u
Generating module: naspp...
(Bundled) cc: warning 922: "+Oshortdata=0" is unsupported in the bundled compiler, ignored.
Requesting loadable module update...

The following modules are activated successfully:
naspp

/tmp/naspp> kmadmin -L naspp
kmadmin: naspp: Object file error in loading kernel module
/tmp/naspp> dmesg -

Jan 15 12:18
WARNING: MOD: mod_obj_relone: Illegal relocation type R_IA_64_LTOFF_TPREL22 154
(0x9a) in module /stand/dlkm.4006C159079B/mod.d/naspp/0.1.0/naspp.

NOTICE: MOD: mod_obj_load: Relocation in module /stand/dlkm.4006C159079B/mod.d/naspp/0.1.0/naspp failed.

[Mike Stroyan]

The cc_bundled on 11.22 will use the R_IA_64_LTOFF_TPREL22 relocation. You should get a real hp C compiler which will use the correct relocation.

(The cc_bundled on 11.23 actually does use R_IA_64_TPREL22 in +kernel mode. I don't know what other problems it may have with building a DLKM.)

[Dmitry Grebenev_2]

I use ANSI C compiler for the module itself (cc: HP ANSI C++/C B3910B A.05.36 [ May 2002]
). The "cc_bundled..." message comes from /usr/conf/gen/config.lm which is hard-coded to use ccs binaries. I actually tried building everything with /opt/ansic/bin/cc and it did not help. I heard that ANSI C 5.50 may resolve the issue...
Thank you.

[Michael Umansky]

So did anyone ever provide a satisfactory answer?
I have a machine with 11.22 on it with the ANSI compiler version A.05.36 (May 20 2002) and I can't get my DLKM modules to load for the same reason as yours, I keep getting the same error message. I even removed cc_bundled and symlinked it to /opt/ansic/bin/cc.
This means that I can't ship my modules to any customer who has 11.22 with that compiler. Is there any solution?
thanks
Michael Umansky

[Cheryl Griffin]

Michael please open your own thread for this topic. Dmitry has not posted since January.

[Dmitry Grebenev_3]

I had to move on to 11.23, since upgrading the compiler (the recommendation I got) to see if the problem goes away was not an option for us + retrofitting a statically linked kernel subsystem that was already shipping with a capability to be installed as a DLKM did not make much sense. On 11.23, no problems of that sort were observed.
Regards, Dmitry

[Michael Umansky_1]

Thank you for the information. From what another member told me it looks like upgrading to 11.23 is the better solution and I guess the customer(s) will have to do the same.
Spasibo
misha