public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
* [Linux-ia64] Re: loading a kernel module
@ 2002-10-15 12:34 Keith Owens
  2002-10-15 18:57 ` Jim Wilson
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Keith Owens @ 2002-10-15 12:34 UTC (permalink / raw)
  To: linux-ia64

On Tue, 15 Oct 2002 13:23:12 +0200, 
Christian Hildner <christian.hildner@hob.de> wrote:
>when doing insmod on my kernel module, I get the error message
>"Unhandled relocation of type 72 for label_name"

Interesting, that looks like this relocation type
  #define R_IA64_PCREL60B         0x48    /* @pcrel(sym + add), brl */
which is not handled by any version of modutils.  I need :-

gcc version (gcc -v)
binutils version (ld -v)
the module .o file (compressed, please).

Send all that data to kaos@ocs.com.au (not the list) so I can update
modutils to handle it.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Linux-ia64] Re: loading a kernel module
  2002-10-15 12:34 [Linux-ia64] Re: loading a kernel module Keith Owens
@ 2002-10-15 18:57 ` Jim Wilson
  2002-10-16  1:16 ` Keith Owens
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Jim Wilson @ 2002-10-15 18:57 UTC (permalink / raw)
  To: linux-ia64

>Interesting, that looks like this relocation type
>  #define R_IA64_PCREL60B         0x48    /* @pcrel(sym + add), brl */
>which is not handled by any version of modutils.  I need :-

That might be an RHL AS toolchain.  The current GNU tools avoid use of brl
because it is implemented via kernel emulation on Itanium hardware, which
causes performance problems for some code.  However, Itanium2 has this
instruction in hardware, and avoiding brl reduces Itanium2 performance, and
presumably anyone who cares about performance is already using Itanium2
hardware, so it makes sense to emit brl by default now.   I think they may
have made this change in the RHL AS toolchain already, but it is unfortunately
not in the FSF sources yet.

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.

Jim



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Linux-ia64] Re: loading a kernel module
  2002-10-15 12:34 [Linux-ia64] Re: loading a kernel module Keith Owens
  2002-10-15 18:57 ` Jim Wilson
@ 2002-10-16  1:16 ` Keith Owens
  2002-10-16  5:52 ` Christian Hildner
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Keith Owens @ 2002-10-16  1:16 UTC (permalink / raw)
  To: linux-ia64

On 15 Oct 2002 14:57:07 -0400, 
Jim Wilson <wilson@redhat.com> wrote:
>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
        ...
  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;;



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Linux-ia64] Re: loading a kernel module
  2002-10-15 12:34 [Linux-ia64] Re: loading a kernel module Keith Owens
  2002-10-15 18:57 ` Jim Wilson
  2002-10-16  1:16 ` Keith Owens
@ 2002-10-16  5:52 ` Christian Hildner
  2002-10-16  7:04 ` Keith Owens
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Christian Hildner @ 2002-10-16  5:52 UTC (permalink / raw)
  To: linux-ia64

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Keith Owens schrieb:

> On 15 Oct 2002 14:57:07 -0400,
> Jim Wilson <wilson@redhat.com> wrote:
> >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.

Keith, Jim,

the source isn't that complex as you might have seen in the length of the objdump output.
The object I have given you is only a small test program to find out the missing linkage for
brl branches. My original program needs brl to branch across virtual pages with a big
difference in the virtual addresses. So the test prog never makes any sence, but shows the
missing R_IA64_PCREL60B nicely.

Christian

PS: Here is the source without any guarantee not to crash ...

[-- Attachment #2: crash.c --]
[-- Type: image/x-xbitmap, Size: 262 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Linux-ia64] Re: loading a kernel module
  2002-10-15 12:34 [Linux-ia64] Re: loading a kernel module Keith Owens
                   ` (2 preceding siblings ...)
  2002-10-16  5:52 ` Christian Hildner
@ 2002-10-16  7:04 ` Keith Owens
  2002-10-16  7:56 ` Christian Hildner
  2002-10-16  9:06 ` Christian Hildner
  5 siblings, 0 replies; 7+ messages in thread
From: Keith Owens @ 2002-10-16  7:04 UTC (permalink / raw)
  To: linux-ia64

On Wed, 16 Oct 2002 07:52:15 +0200, 
Christian Hildner <christian.hildner@hob.de> wrote:
>the source isn't that complex as you might have seen in the length of the objdump output.
>The object I have given you is only a small test program to find out the missing linkage for
>brl branches. My original program needs brl to branch across virtual pages with a big
>difference in the virtual addresses. So the test prog never makes any sence, but shows the
>missing R_IA64_PCREL60B nicely.
>
>Christian
>
>PS: Here is the source without any guarantee not to crash ...
>
>#define MODULE
>#include <linux/module.h>
>
>int dummy(void)
>{
>    return 0;
>}
>
>int init_module(void)
>{
>    printk("Init Module starting. About to crash...\n");
>    asm volatile ("brl dummy ");
>    return 0;
>}
>
>void cleanup_module(void)
>{
>    printk("Done\n");
>}

OK, so it is not a toolchain problem, this is user code.  Unfortunately
it is introducing a special case into modutils.

All existing PCREL relocations in modutils go via a PLT, saving and
switching GP as they do so.  I am assuming that branching via the PLT
is no good for you, you really do want a direct branch over the 64 bit
address space, without any change to GP.  That is, the source and
target addresses use the same global data area, or one of them does not
use any global data area at all.  Please confirm this before I make any
changes.

If you need different GP values in the source and target addresses then
a normal PCREL21 via PLT will do the job.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Linux-ia64] Re: loading a kernel module
  2002-10-15 12:34 [Linux-ia64] Re: loading a kernel module Keith Owens
                   ` (3 preceding siblings ...)
  2002-10-16  7:04 ` Keith Owens
@ 2002-10-16  7:56 ` Christian Hildner
  2002-10-16  9:06 ` Christian Hildner
  5 siblings, 0 replies; 7+ messages in thread
From: Christian Hildner @ 2002-10-16  7:56 UTC (permalink / raw)
  To: linux-ia64

Keith Owens schrieb:

> On Wed, 16 Oct 2002 07:52:15 +0200,
> Christian Hildner <christian.hildner@hob.de> wrote:
> >the source isn't that complex as you might have seen in the length of the objdump output.
> >The object I have given you is only a small test program to find out the missing linkage for
> >brl branches. My original program needs brl to branch across virtual pages with a big
> >difference in the virtual addresses. So the test prog never makes any sence, but shows the
> >missing R_IA64_PCREL60B nicely.
> >
> >Christian
> >
> >PS: Here is the source without any guarantee not to crash ...
> >
> >#define MODULE
> >#include <linux/module.h>
> >
> >int dummy(void)
> >{
> >    return 0;
> >}
> >
> >int init_module(void)
> >{
> >    printk("Init Module starting. About to crash...\n");
> >    asm volatile ("brl dummy ");
> >    return 0;
> >}
> >
> >void cleanup_module(void)
> >{
> >    printk("Done\n");
> >}
>
> OK, so it is not a toolchain problem, this is user code.  Unfortunately
> it is introducing a special case into modutils.
>
> All existing PCREL relocations in modutils go via a PLT, saving and
> switching GP as they do so.  I am assuming that branching via the PLT
> is no good for you, you really do want a direct branch over the 64 bit
> address space, without any change to GP.  That is, the source and
> target addresses use the same global data area, or one of them does not
> use any global data area at all.  Please confirm this before I make any
> changes.
>
> If you need different GP values in the source and target addresses then
> a normal PCREL21 via PLT will do the job.

What I want to do is a simple branch without any side effects like adjusting GP. I am doing a
branch like brl (local_label + PAGE_OFFSET) where PAGE_OFFSET is the distance between the two
"shadowed" pages. Maybe there is a way to tell the compiler/assembler not to make a linkage entry
for that branch. There is no addressing of any data segment by the means of GP in my program.

Christian



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Linux-ia64] Re: loading a kernel module
  2002-10-15 12:34 [Linux-ia64] Re: loading a kernel module Keith Owens
                   ` (4 preceding siblings ...)
  2002-10-16  7:56 ` Christian Hildner
@ 2002-10-16  9:06 ` Christian Hildner
  5 siblings, 0 replies; 7+ messages in thread
From: Christian Hildner @ 2002-10-16  9:06 UTC (permalink / raw)
  To: linux-ia64

Keith, Jim,

I found the error in my prog. I wrongly specified brl against a ".global" symbol. Doing brl
against a symbol that is not global does not irritate insmod anymore. For this reason, I do
not need any modification of modutils this time. Sorry for time you spent on this and for
the noise on the list.

Christian



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2002-10-16  9:06 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-15 12:34 [Linux-ia64] Re: loading a kernel module Keith Owens
2002-10-15 18:57 ` Jim Wilson
2002-10-16  1:16 ` Keith Owens
2002-10-16  5:52 ` Christian Hildner
2002-10-16  7:04 ` Keith Owens
2002-10-16  7:56 ` Christian Hildner
2002-10-16  9:06 ` Christian Hildner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox