DLKM, Overrun of module DLT or long branch stub table

[Ian Norton]

Hello,

I have a 11.31/11.23 kernel module that I am adding DLKM support to, I've been able to build the module and it still works as a static module but when I try to load it dynamically I see this in the kernel logs:

WARNING: MOD: mod_obj_relone: Overrun of module DLT or long branch stub table for module /stand/current/mod/mymod.
NOTICE: MOD: mod_obj_load: Relocation in module /stand/current/mod/mymod failed.

I have read recently that this *might* be due to having too large/many statics or perhaps bad compiler flags. My compiler flags are the same as those produced by the sample drivers in the DDK except (for some reason unknown to me) +DSblended is added just before +DSitanium2

How can I figure out if this is due to going past some size boundary or not?

Thanks

Ian

[Ian Norton]

I should add that the sample drivers do all load properly.

[Dennis Handly]

How big is the object file? Can you attach it here?
Are you using +Oshortdata=0 +kernel?
What does this show?
elfdump -S -h module

[Ian Norton]

The object is 120616 bytes,
elfdump output below:
--->8---
Index Type Vaddr Offset Size Name

1 UNWI 0000000000000000 0000000000000040 000005e8 .IA_64.unwind
2 RELA 0000000000000000 0000000000000628 000011b8 .rela.IA_64.unwind
3 PBIT 0000000000000000 00000000000017e0 00000ab0 .IA_64.unwind_info
4 RELA 0000000000000000 0000000000002290 000005e8 .rela.IA_64.unwind_info
5 HP_O 0000000000000000 0000000000002878 00000608 .HP.opt_annot
6 RELA 0000000000000000 0000000000002e80 00000030 .rela.HP.opt_annot
7 PBIT 0000000000000000 0000000000002eb0 00002196 .rodata
8 RELA 0000000000000000 0000000000005048 000004c8 .rela.rodata
9 PBIT 0000000000000000 0000000000005520 0000a5b0 .text
10 RELA 0000000000000000 000000000000fad0 00003cd8 .rela.text
11 PBIT 0000000000000000 00000000000137b0 00000200 .data
12 RELA 0000000000000000 00000000000139b0 000001f8 .rela.data
13 PBIT 0000000000000000 0000000000013bb0 00000290 .data.KC_META
14 RELA 0000000000000000 0000000000013e40 00000018 .rela.data.KC_META
15 PBIT 0000000000000000 0000000000013e58 00000008 .data.KC_META_PTR
16 RELA 0000000000000000 0000000000013e60 00000018 .rela.data.KC_META_PTR
17 NOBI 0000000000000000 0000000000013e78 00000008 .bss
18 NOTE 0000000000000000 0000000000013e78 00001d08 .note
19 PBIT 0000000000000000 0000000000015b80 0000151a .debug_line
20 RELA 0000000000000000 000000000001709c 000005e8 .rela.debug_line
21 PBIT 0000000000000000 0000000000017688 00001f50 .debug_actual
22 RELA 0000000000000000 00000000000195d8 000005e8 .rela.debug_actual
23 PBIT 0000000000000000 0000000000019bc0 0000010e .debug_procs_abbrev
24 PBIT 0000000000000000 0000000000019cce 00000daa .debug_procs_info
25 RELA 0000000000000000 000000000001aa78 00000d38 .rela.debug_procs_info
26 STRT 0000000000000000 000000000001b7b0 00000833 .strtab
27 SYMT 0000000000000000 000000000001bfe8 00000d38 .symtab
28 STRT 0000000000000000 000000000001cd20 000001b6 .shstrtab
29 DLKM 0000000000000000 000000000001ced8 0000001b .shtmod
30 RELA 0000000000000000 000000000001cef4 00000018 .rela.shtmod
31 PBIT 0000000000000000 000000000001cf10 00000018 .IA_64.unwind_hdr

[Ian Norton]

my compiler flags are:-

cc +DD64 +DSblended -c -Ae +DD64 +O2 +DSitanium2 +kernel +objstatvars +Olit=all +Oshortdata=0 +W863 -DACLS -DAUDIT -DHPONCPLUS -DIDDS -DIPSEC -DIVT_INTERCEPT -DLWSYSCALL -DPGPROF -DSTCP -D_CLEAN_BE -D_HPUX_SOURCE -D_KERNEL -D_LARGEFILE64_SOURCE -D_NO_USER_PROTOS -D_UNSUPPORTED -D__BIGMSGQUEUE_ENABLED -D__ROSE__ -U__hp9000s700 -D_XPG4_EXTENDED -DKERNEL_DEBUGGER -DVARIABLE_UAREA -D_SYSCALL_64 -D__NO_PA_HDRS

[Dennis Handly]

>I have a 11.31/11.23 kernel module

You can't use the same module for both.
What version of aC++ are you using? And what HP-UX version?

>The object is 120616 bytes

Can you please attach a gzipped copy of your module.

[Ian Norton]

Hello,

> have a 11.31/11.23 kernel module

Yes, I have two different systems that this builds on and various #ifdefs to address the DDK differences. At the moment I'm only trying to get it to work on 11.23.

> gzip copy,

Sorry; Unfortunately I can't release the object file.

Thank's for your time.

Ian

[Dennis Handly]

>I can't release the object file.

Then can you use "elfdump -r module" and attach that output.

[Ian Norton]

Thanks, elfdump -r output attached,

[Dennis Handly]

What does this show?
elfdump -n .shtmod -s module

Again, what version of aC++ are you using?

[Ian Norton]

Hi Denis,

my compiler is HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006]

"elfdump -n .shtmod" output:

.shtmod:
00000002 00000000 00000000 00000000 00000000 00000000 000000

Many thanks

Ian

[Dennis Handly]

.shtmod:
00000002 00000000 00000000 00000000 00000000 00000000 000000

This says: Version: 2, LBS: 0, DLT: 0

To compute the number of stubs, I would need to see:
elfdump -t module

If you don't want to provide YOUR symbols, then you can just grep for "UNDEF" and provide those.

Looking at the PCREL21BI relocations, it seems that bcopy, bzero, kfree, kmalloc, sleep, spinlock, spinunlock, strlen, etc would all need stubs.

Also, what version of ld are you using?
What is your $PATH?

[Ian Norton]

> linker

ld: 92453-07 linker ld HP Itanium(R) B.12.47 IPF/IPF

> elfdump -t mod |grep UNDEF

0 NOTY LOCL 0 UNDEF 0x0000000000000000 0
102 FUNC GLOB 3 UNDEF 0x0000000000000000 0 physio
103 FUNC GLOB 3 UNDEF 0x0000000000000000 0 wakeup
104 FUNC GLOB 3 UNDEF 0x0000000000000000 0 dealloc_spinlock
105 FUNC GLOB 3 UNDEF 0x0000000000000000 0 kmalloc
106 OBJT GLOB 3 UNDEF 0x0000000000000000 0 gio_mod_ops
107 FUNC GLOB 3 UNDEF 0x0000000000000000 0 selwakeup
108 FUNC GLOB 3 UNDEF 0x0000000000000000 0 wsio_get_isc
109 FUNC GLOB 3 UNDEF 0x0000000000000000 0 mod_wsio_attach_list_remove
110 FUNC GLOB 3 UNDEF 0x0000000000000000 0 get_sleep_lock
111 FUNC GLOB 3 UNDEF 0x0000000000000000 0 spinunlock
112 FUNC GLOB 3 UNDEF 0x0000000000000000 0 bcopy
114 OBJT GLOB 3 UNDEF 0x0000000000000000 0 pci_attach
115 FUNC GLOB 3 UNDEF 0x0000000000000000 0 printf
116 FUNC GLOB 3 UNDEF 0x0000000000000000 0 isrlink
117 FUNC GLOB 3 UNDEF 0x0000000000000000 0 spinlock
118 FUNC GLOB 3 UNDEF 0x0000000000000000 0 isrunlink
119 FUNC GLOB 3 UNDEF 0x0000000000000000 0 minphys
120 OBJT GLOB 3 UNDEF 0x0000000000000000 0 uniprocessor
121 FUNC GLOB 3 UNDEF 0x0000000000000000 0 wsio_uninstall_driver
122 FUNC GLOB 3 UNDEF 0x0000000000000000 0 biodone
123 FUNC GLOB 3 UNDEF 0x0000000000000000 0 kfree
124 FUNC GLOB 3 UNDEF 0x0000000000000000 0 bzero
125 FUNC GLOB 3 UNDEF 0x0000000000000000 0 sleep
127 FUNC GLOB 3 UNDEF 0x0000000000000000 0 map_mem_to_host
128 FUNC GLOB 3 UNDEF 0x0000000000000000 0 uiomove
129 FUNC GLOB 3 UNDEF 0x0000000000000000 0 isc_claim
130 FUNC GLOB 3 UNDEF 0x0000000000000000 0 alloc_spinlock
131 FUNC GLOB 3 UNDEF 0x0000000000000000 0 waiting_in_select
133 OBJT GLOB 3 UNDEF 0x0000000000000000 0 _u_default
134 FUNC GLOB 3 UNDEF 0x0000000000000000 0 wsio_install_driver
135 FUNC GLOB 3 UNDEF 0x0000000000000000 0 unmap_mem_from_host
136 FUNC GLOB 3 UNDEF 0x0000000000000000 0 mod_wsio_attach_list_add
137 FUNC GLOB 3 UNDEF 0x0000000000000000 0 strlen
138 FUNC GLOB 3 UNDEF 0x0000000000000000 0 timeout
139 FUNC GLOB 3 UNDEF 0x0000000000000000 0 untimeout

Thanks again for all your help so far!

Ian

[Dennis Handly]

> elfdump -t mod | grep UNDEF

You should have at least:
$ grep -c "FUNC GLOB" 357483.ed
31 (LBS)
$ grep -c "OBJT GLOB" 357483.ed
4 (DLTs)

Somehow it isn't creating the module correctly.
Do you have some foreign devil tools in /usr/local/bin in your $PATH before /usr/bin or /usr/ccs/bin?

[Ian Norton]

Hmm I might somehow have the GNU version of as ahead of /usr/ccs/bin/as, I'll check and let you know. Thanks

[Ian Norton]

With /usr/ccs/bin at the start of $PATH I now get:

WARNING: MOD: mod_obj_relone: Illegal relocation type R_IA_64_GPREL22 42 (0x2a) in module /stand/current/mod/mymod. It may be due to incorrect compiler/linker options when building the module.

Looks like I have some double checking of our build system to do, many thanks.

[Dennis Handly]

>MOD: mod_obj_relone: Illegal relocation type R_IA_64_GPREL22

Hmm, I didn't see that relocation in your previous "elfdump -r", just TPREL22.

[Dennis Handly]

>Looks like I have some double checking of our build system to do

You meed to make sure your $PATH don't have /usr/ccs/bin before /usr/bin or /opt/aCC/bin or /opt/ansic/bin. Otherwise you'll be using cc_bundled(1) which doesn't support +Oshortdata=0, which prevents that R_IA_64_GPREL22.

[Ian Norton]

> You meed to make sure your $PATH don't have /usr/ccs/bin before /usr/bin or /opt/aCC/bin or /opt/ansic/bin.

Ah that is exactly what I've done ( added /usr/ccs/bin right at the start ).

Would GNU as rather than the HP one be a problem?

[Dennis Handly]

>Would GNU as rather than the HP one be a problem?

(You have some words missing?)

You have two problems. You must have the right compiler first in the path, aC++. You must have the right HP-UX tools before the foreign devil GNU tools.

You may want to use tusc to see what actual process are being executed when you build your module.
tusc -fp -ea -o tusc.out command ...

[EricRen]

for hp-ux 11iv1 11iv2 11iv3 

add /usr/bin to $PATH, make it is the front of the $PATH

have a look at https://kc.mcafee.com/corporate/index?page=content&id=KB66492

and http://h30499.www3.hp.com/t5/Languages-and-Scripting/DLKM-load-module-meet-a-strange-problem/td-p/5164196

which nm for kernel module  is very important !!!