Skip to contentSkip to conversation

PCREL60B - toolchain error? (was: loading a kernel module)

Linux-ia64 Keith Owens 1 participant 1 message Oct 16, 2002

lore
Share & tools
lore

Keith Owens

author
#0 lore raw
Quoted 27 lines · Keith Owens
Quoted 4 lines · Jim Wilson

You can get brl instructions by changing "#undef USE_BRL" to "#define USE_BRL" in the BINUTILS bfd/elfxx-ia64.c file. I believe that is the change that went into the RHL AS toolchain. Then write a large enough program, so that you have a call site that is far enough away from its call target to require brl.

You don't need a large program. The test object from Christian Hildner is about as small as it gets and it still uses brl. Christian, please post the source of the test object to the list.

0000000000000000 <dummy>:

  0:   1d 40 00 00 00 21       [MFB]       mov r8=r0
  6:   00 00 00 02 00 80                   nop.f 0x0
  c:   08 00 84 00                         br.ret.sptk.many b0;;

0000000000000010 <init_module>:
10: 01 10 11 06 80 05 [MII] alloc r34=ar.pfs,4,3,0

                       12: LTOFF22     .rodata
 16:   10 02 00 62 00 60                   mov r33°
 1c:   04 08 00 90                         addl r35=0,r1;;
 20:   1d 18 01 46 18 10       [MFB]       ld8 r35=[r35]
                       22: PCREL21B    printk
 26:   00 00 00 02 00 00                   nop.f 0x0
 2c:   08 00 00 50                         br.call.sptk.many b0  <init_module+0x10>;;
 30:   05 00 00 00 01 00       [MLX]       nop.m 0x0

32: PCREL60B dummy

Quoted 8 lines

...

 3e:   00 c0 00 40                         brl.few 30 <init_module+0x20>;;
 42:   00 00 00 21 00 10       [MII]       mov r8=r0
 48:   01 55 00 00 10 0a                   mov.i ar.pfs=r34
 4e:   00 07 1d 00                         mov b0=r33
 52:   00 00 01 00 00 00       [MFB]       nop.m 0x0
 58:   00 02 00 80 08 00                   nop.f 0x0
 5e:   84 00 01 10                         br.ret.sptk.many b0;;

The more I look at this code, the less sense it makes. The toolchain is issuing brl with PCREL60B for dummy, even though dummy is a local symbol. That would normally be br.call.sptk.many b0=0 <dummy>, with no relocation at all.

Not only is the brl using an entire slot, it also has to go via the PLT, like all the other PCREL relocations in modules. But the PLT is local, so why use a 60 bit relocation? The call to printk goes via PLT and that happily uses a 21 bit relocation.

This looks like a toolchain bug which modutils should not be supporting. Unless somebody has a decent reason why this is _not_ a toolchain bug, I am going to bounce it back to binutils and/or RedHat, with no change to modutils.