* 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