R_PPC_ADDR16_HI relocs in PPC modules ?

Hi,

I'm currently trying to port a binary-only driver to Linux/PPC using a
MacOS X driver as a starting point. "Translating" this driver to ELF32
gives an object that links into a .ko without too much problems.

However, trying to insmod the resulting object gives the following
error message:

unknown ADD relocation: 5

which refers to R_PPC_ADDR16_HI relocations. The error message comes
from apply_relocate_add() in arch/powerpc/kernel/module_32.c, which
deals with R_PPC_ADDR16_LO and R_PPC_ADDR16_HA relocs, but not
R_PPC_ADDR16_HI ones.

Is there a reason for this ? Those relocs directly come from the
mapping of PPC_RELOC_HI16 in the original driver, and i'd rather not
transpose them into R_PPC_ADDR16_HA.

If there are no reasons, then how about the following patch ?
(this is against 2.6.18.1, but the problem is still present in 2.6.19 kernels)

--- arch/powerpc/kernel/module_32.c.orig	2007-01-02 17:07:21.000000000 +0100
+++ arch/powerpc/kernel/module_32.c	2007-01-02 17:11:55.000000000 +0100

@@ -222,6 +222,11 @@ int apply_relocate_add(Elf32_Shdr *sechd
 			*(uint16_t *)location = value;
 			break;
 		
+		case R_PPC_ADDR16_HI:
+			/* Higher half of the symbol */
+			*(uint16_t *)location = (value >> 16);
+			break;
+
 		case R_PPC_ADDR16_HA:
 			/* Sign-adjusted lower 16 bits: PPC ELF ABI says:
 			   (((x >> 16) + ((x & 0x8000) ? 1 : 0))) & 0xFFFF.

Note that I'm quite new to the kernel in general, so feel free to point me to 
another list if you think my questions are inappropriate here.

Simon

unknown ADD relocation: 5

which refers to R_PPC_ADDR16_HI relocations. The error message comes
from apply_relocate_add() in arch/powerpc/kernel/module_32.c, which
deals with R_PPC_ADDR16_LO and R_PPC_ADDR16_HA relocs, but not
R_PPC_ADDR16_HI ones.

Is there a reason for this ? Those relocs directly come from the
mapping of PPC_RELOC_HI16 in the original driver, and i'd rather not
transpose them into R_PPC_ADDR16_HA.

Well you normally never end up with an add with an @h -- you're
typically adding it to something that is loaded with "li", i.e.,
something that's the sign-extended version of the low 16 bits of
the 32-bit thing you're loading totally.

I'm interested how (and why :-) ) Darwin ends up doing it; could
you send me the (original) file in question?  Or an otool -tvV
of it, or part thereof that shows the problem.


Segher

On Tue, 2 Jan 2007 18:16:01 +0100
Segher Boessenkool [off-list ref] wrote:

Well you normally never end up with an add with an @h -- you're
typically adding it to something that is loaded with "li", i.e.,
something that's the sign-extended version of the low 16 bits of
the 32-bit thing you're loading totally.

Mmm... I might need to get a deeper understanding of apply_relocate_add(), 
but if I'm not mistaken, ha also uses high bits

I'm interested how (and why :-) ) Darwin ends up doing it; could
you send me the (original) file in question?  Or an otool -tvV
of it, or part thereof that shows the problem.

Sure. As an example, here is some output of otool -rV and the corresponding 
disassembled text section part

Relocation information (__TEXT,__text) 61126 entries
address  pcrel length extern type    scattered symbolnum/value
00000664 False long   False  LO16    False     1 (__TEXT,__text)
         False long   False  PAIR    False     half = 0x0000
00000660 False long   False  HI16    False     1 (__TEXT,__text)
         False long   False  PAIR    False     half = 0x2738
00000654 False long   False  LO16    False     1 (__TEXT,__text)
         False long   False  PAIR    False     half = 0x0000
00000650 False long   False  HI16    False     1 (__TEXT,__text)
         False long   False  PAIR    False     half = 0x83fc

00000650        lis     r12,hi16(_msw_report_event)
00000654        ori     r12,r12,lo16(_msw_report_event)
00000658        mtspr   ctr,r12
0000065c        bctr
00000660        lis     r12,hi16(_PRINT_ERROR)
00000664        ori     r12,r12,lo16(_PRINT_ERROR)
00000668        mtspr   ctr,r12
0000066c        bctr

As for the two symbols:
000083fc T _msw_report_event
00002738 T _PRINT_ERROR

Just tell me if you need more info.

Simon

On Tue, 2007-01-02 at 17:25 +0100, Simon Vallet wrote:

Hi,

I'm currently trying to port a binary-only driver to Linux/PPC using a
MacOS X driver as a starting point. "Translating" this driver to ELF32
gives an object that links into a .ko without too much problems.

However, trying to insmod the resulting object gives the following
error message:

unknown ADD relocation: 5

We only add relocation to the kernel loader as we need them... since
this relocation has never been generated so far for in kernel modules it
wasn't added...

BTW. What is this evil^H^H^H^Hbinary driver you are talking about ?

Ben.

Sure. As an example, here is some output of otool -rV and the 
corresponding
disassembled text section part

Relocation information (__TEXT,__text) 61126 entries
address  pcrel length extern type    scattered symbolnum/value
00000654 False long   False  LO16    False     1 (__TEXT,__text)
         False long   False  PAIR    False     half = 0x0000
00000650 False long   False  HI16    False     1 (__TEXT,__text)
         False long   False  PAIR    False     half = 0x83fc

00000650        lis     r12,hi16(_msw_report_event)
00000654        ori     r12,r12,lo16(_msw_report_event)

Ah.  lis and ori.  HI16 is just fine there -- but note that
that doesn't use an add insn.  You're patching the function
"apply_relocate_add()", so I guess some more work is needed?


Segher

On Tue, Jan 02, 2007 at 05:25:54PM +0100, Simon Vallet wrote:

Is there a reason for this ?

I guess no one has needed the reloc before.  gcc tends to use
"li, addis" pairs to load 32-bit constants.  Your code must be using
"lis, ori".

If there are no reasons, then how about the following patch ?

Looks good to me.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Segher Boessenkool writes:

Ah.  lis and ori.  HI16 is just fine there -- but note that
that doesn't use an add insn.  You're patching the function

lis is an addis with rA=0, don't forget...

"apply_relocate_add()", so I guess some more work is needed?

Looks fine as it is to me.

Paul.

quoted

Ah.  lis and ori.  HI16 is just fine there -- but note that
that doesn't use an add insn.  You're patching the function

lis is an addis with rA=0, don't forget...

Heh true.  "I never forget that" ;-)

quoted

"apply_relocate_add()", so I guess some more work is needed?

Looks fine as it is to me.

Looking at the bigger code, fine with me as well.  Confusing
names are in the nature of this relocation stuff (esp. when
you start adding those ELF-defined "names").


Segher

apply_relocate_add() does not support R_PPC_ADDR16_HI relocations, which
prevents some non gcc-built modules to be loaded.

Signed-off-by: Simon Vallet <redacted>
---

diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 8339fd6..07a89a3 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c

@@ -224,7 +224,12 @@ int apply_relocate_add(Elf32_Shdr *sechdrs,
 			/* Low half of the symbol */
 			*(uint16_t *)location = value;
 			break;
-		
+
+		case R_PPC_ADDR16_HI:
+			/* Higher half of the symbol */
+			*(uint16_t *)location = (value >> 16);
+			break;
+
 		case R_PPC_ADDR16_HA:
 			/* Sign-adjusted lower 16 bits: PPC ELF ABI says:
 			   (((x >> 16) + ((x & 0x8000) ? 1 : 0))) & 0xFFFF.

On Wed, 03 Jan 2007 07:41:26 +1100
Benjamin Herrenschmidt [off-list ref] wrote:

BTW. What is this evil^H^H^H^Hbinary driver you are talking about ?

Yes, blobs are evil, but a binary driver is still better than no driver
at all...

I'm working on the unicorn driver for the BeWan ADSL PCI card -- the
card manufacturer does not seem willing to provide the relevant info
(I'm not really aware of the specifics -- Sven Luther will probably
know more about this). Besides, much of the functionality of the card
is implemented in software, so a 100% open-source driver would probably
require a lot of work.

Last but not least I wanted to dig a bit into binary formats anyway ;-)

Simon

On Wed, 2007-01-03 at 08:01 +0100, Simon Vallet wrote:

On Wed, 03 Jan 2007 07:41:26 +1100
Benjamin Herrenschmidt [off-list ref] wrote:

quoted

BTW. What is this evil^H^H^H^Hbinary driver you are talking about ?

Yes, blobs are evil, but a binary driver is still better than no driver
at all...

I'm working on the unicorn driver for the BeWan ADSL PCI card -- the
card manufacturer does not seem willing to provide the relevant info
(I'm not really aware of the specifics -- Sven Luther will probably
know more about this). Besides, much of the functionality of the card
is implemented in software, so a 100% open-source driver would probably
require a lot of work.

Last but not least I wanted to dig a bit into binary formats anyway ;-)

Doh ! I've been in "contact" with that driver in a previous life... it's
a whole bunch of horrid C++ with windows wrappers all over... or did
they improve it ? It's still an ST chip ?

Ben.

On Wed, 03 Jan 2007 20:58:12 +1100
Benjamin Herrenschmidt [off-list ref] wrote:

Doh ! I've been in "contact" with that driver in a previous life... it's
a whole bunch of horrid C++ with windows wrappers all over... or did
they improve it ? It's still an ST chip ?

Well -- obviously I can't tell much about the source ;-), but it
certainly looks like C++ to me. The last version of the driver is some
years old, actually, so it probably hasn't changed much since you were
"in contact" with it -- and yes, as far as I know the card still uses an
ST chipset.

Since you're somewhat familiar with this driver, do you
think the ELF translation approach is a viable one ?

Simon

On Wed, 2007-01-03 at 11:32 +0100, Simon Vallet wrote:

On Wed, 03 Jan 2007 20:58:12 +1100
Benjamin Herrenschmidt [off-list ref] wrote:

quoted

Doh ! I've been in "contact" with that driver in a previous life... it's
a whole bunch of horrid C++ with windows wrappers all over... or did
they improve it ? It's still an ST chip ?

Well -- obviously I can't tell much about the source ;-), but it
certainly looks like C++ to me. The last version of the driver is some
years old, actually, so it probably hasn't changed much since you were
"in contact" with it -- and yes, as far as I know the card still uses an
ST chipset.

Since you're somewhat familiar with this driver, do you
think the ELF translation approach is a viable one ?

No idea.

Ben.