How to printk/sprintf uint64_t on Sparc without format and argument types mismatch
Vladislav Bolkhovitin
We in SCST project need to printk/sprintf variables of type uint64_t.
Size of those variables is required to be 64-bit integer. On x86 we
printk/sprintf them as %lld, but on Sparc we have a compiler warnings like:
scst/src/scst_targ.c:2136: warning: format ‘%llx’ expects type ‘long
long unsigned int’, but argument 4 has type ‘uint64_t’.
It is because on Sparc uint64_t defined as unsigned long, but on x86 -
as unsigned long long.
Sure, we can cast all the cases to unsigned long long, but we wonder,
maybe there is a more elegant way to do that without the warning? For
instance, like %z for size_t or PRId64 in the user space.
Thanks,
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Vladislav Bolkhovitin
We in SCST project have a very strange problem on Sparc. Our main module
scst.ko, if built as a module out of the kernel tree, can't be loaded
and "modprobe scst" returns:
FATAL: Error inserting scst
(/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format
The following message is immediately spit out by the kernel:
[ 1686.676534] module scst: Unknown relocation: 36
On x86 everything works fine. If SCST built inside the kernel, on Sparc
it also works fine.
We completely stuck and have no idea what could be the cause. Googling
also doesn't help much.
Could anybody point out a direction how to find the cause of the issue?
I'm attaching Makefile we are using for you reference.
Thanks,
Vlad
Kyle McMartin
> scst/src/scst_targ.c:2136: warning: format ?%llx? expects type ?long
> long unsigned int?, but argument 4 has type ?uint64_t?.
>
> It is because on Sparc uint64_t defined as unsigned long, but on x86 -
> as unsigned long long.
>
From your other mail, it looks like you're using 2.6.26... this is
ancient! Sparc has since been fixed to use unsigned long long for u64.
commit 9018113649348c689da107166c05d436cd52e7bf
Author: Sam Ravnborg <s...@ravnborg.org>
Date: Tue Jan 6 13:19:28 2009 -0800
sparc64: Use unsigned long long for u64.
regards, Kyle
Kyle McMartin
> FATAL: Error inserting scst
> (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format
>
> The following message is immediately spit out by the kernel:
> [ 1686.676534] module scst: Unknown relocation: 36
>
The error is caused because gcc is generating a relocation type that the
kernel's module loader cannot handle.
This appears to be:
libelf/elf.h:#define R_SPARC_LM22 36 /* Low middle 22
bits of ... */
It doesn't occur when patched into the kernel build, since the
relocations are handled at link time as opposed to load time.
arch/sparc/kernel/module.c needs to be patched to support the new
relocation type... Based on binutils/gas/config/tc-sparc.c and gold's
sparc config this looks to be the same as the hi22 reloc...
Can you test the following patch?
regards, Kyle
---
diff --git a/arch/sparc/include/asm/elf_64.h b/arch/sparc/include/asm/elf_64.h
index e678803..8bf59f1 100644
--- a/arch/sparc/include/asm/elf_64.h
+++ b/arch/sparc/include/asm/elf_64.h
@@ -52,6 +52,7 @@
#define R_SPARC_11 31
#define R_SPARC_64 32
#define R_SPARC_OLO10 33
+#define R_SPARC_LM22 36
#define R_SPARC_WDISP16 40
#define R_SPARC_WDISP19 41
#define R_SPARC_7 43
diff --git a/arch/sparc/kernel/module.c b/arch/sparc/kernel/module.c
index f848aad..49b1b21 100644
--- a/arch/sparc/kernel/module.c
+++ b/arch/sparc/kernel/module.c
@@ -207,6 +207,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs,
*loc32 = (*loc32 & ~0x3ff) | (v & 0x3ff);
break;
+ case R_SPARC_LM22:
case R_SPARC_HI22:
*loc32 = (*loc32 & ~0x3fffff) |
((v >> 10) & 0x3fffff);
David Miller
Date: Wed, 16 Jun 2010 15:22:57 -0400
> arch/sparc/kernel/module.c needs to be patched to support the new
> relocation type... Based on binutils/gas/config/tc-sparc.c and gold's
> sparc config this looks to be the same as the hi22 reloc...
>
> Can you test the following patch?
This change is incorrect.
LM22 relocations do not get emitted for the "medlow" code model, which
is what is explicitly specified on the kernel compiler command line
for sparc64 via "-mcmodel=medlow".
Someone this person is using incorrect CFLAGS when building their
module, and that's why they have this problem, because the compiler's
default code model on sparc64 can generate those relocations.
David Miller
Date: Wed, 16 Jun 2010 23:05:41 +0400
> We in SCST project have a very strange problem on Sparc. Our main
> module scst.ko, if built as a module out of the kernel tree, can't be
> loaded and "modprobe scst" returns:
>
> FATAL: Error inserting scst
> (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format
>
> The following message is immediately spit out by the kernel:
> [ 1686.676534] module scst: Unknown relocation: 36
You're building the module with incorrect compiler flags, in
particular somehow the "-mcmodel=medlow" option is not getting passed
into the module build and thus the wrong code model is being used to
build the module.
There are a host of other sparc64 specific compiler options that must
be present for a correct build as well. The only way to get it done
correctly is to properly inherit the option settings made by
arch/sparc/Makefile and friends in the kernel tree.
David Miller
Date: Wed, 16 Jun 2010 23:08:03 +0400
> We in SCST project need to printk/sprintf variables of type
> uint64_t. Size of those variables is required to be 64-bit integer. On
> x86 we printk/sprintf them as %lld, but on Sparc we have a compiler
> warnings like:
>
> scst/src/scst_targ.c:2136: warning: format ‘%llx’ expects type ‘long
> long unsigned int’, but argument 4 has type ‘uint64_t’.
>
> It is because on Sparc uint64_t defined as unsigned long, but on x86 -
> as unsigned long long.
Kyle McMartin
> This change is incorrect.
>
> LM22 relocations do not get emitted for the "medlow" code model, which
> is what is explicitly specified on the kernel compiler command line
> for sparc64 via "-mcmodel=medlow".
>
> Someone this person is using incorrect CFLAGS when building their
> module, and that's why they have this problem, because the compiler's
> default code model on sparc64 can generate those relocations.
>
Yeah, just saw your other mail. Thanks for the explanation!
--Kyle
Vladislav Bolkhovitin
David Miller, on 06/17/2010 12:35 AM wrote:
> From: Vladislav Bolkhovitin <v...@vlnb.net>
> Date: Wed, 16 Jun 2010 23:05:41 +0400
>
>> We in SCST project have a very strange problem on Sparc. Our main
>> module scst.ko, if built as a module out of the kernel tree, can't be
>> loaded and "modprobe scst" returns:
>>
>> FATAL: Error inserting scst
>> (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format
>>
>> The following message is immediately spit out by the kernel:
>> [ 1686.676534] module scst: Unknown relocation: 36
>
> You're building the module with incorrect compiler flags, in
> particular somehow the "-mcmodel=medlow" option is not getting passed
> into the module build and thus the wrong code model is being used to
> build the module.
>
> There are a host of other sparc64 specific compiler options that must
> be present for a correct build as well. The only way to get it done
> correctly is to properly inherit the option settings made by
> arch/sparc/Makefile and friends in the kernel tree.
Thank you. This gives us the direction away from the current dead end.
We will make the needed changes in our Makefiles.
But we surprised that such platform specific compiler flags have to be
manually maintained by out of the kernel tree modules developers. We
thought kbuild environment doing it automatically. Particularly,
Documentation/kbuild/modules.txt doesn't say anything about manual
platform specific flags.
I added kbuild developers on CC and attached again our Makefile just in
case if they would like to look at it.
Thanks,
Vlad
Sam Ravnborg
>
> David Miller, on 06/17/2010 12:35 AM wrote:
>> From: Vladislav Bolkhovitin <v...@vlnb.net>
>>
>> particular somehow the "-mcmodel=medlow" option is not getting passed
>> into the module build and thus the wrong code model is being used to
>> build the module.
>>
> We will make the needed changes in our Makefiles.
>
> But we surprised that such platform specific compiler flags have to be
> manually maintained by out of the kernel tree modules developers. We
> thought kbuild environment doing it automatically. Particularly,
> Documentation/kbuild/modules.txt doesn't say anything about manual
> platform specific flags.
They should all be there automagically.
A few things to try out...
What machine is this being build on?
Your Makefile contains this:
> ifeq ($(KVER),)
> ifeq ($(KDIR),)
> KVER = $(shell uname -r)
> KDIR := /lib/modules/$(KVER)/build
> endif
> else
> KDIR := /lib/modules/$(KVER)/build
> endif
>
But does /lib/modules/... contain a sparc kernel?
You could try to build your module using: V=1
And reply with the output. This should give a clue about what flags are picked
up from where.
Most of your Makefile looks fine - I guess we need to find the bug
in the build environmnet and not in the Makefile.
Sam
David Miller
Date: Tue, 22 Jun 2010 23:07:51 +0400
> But we surprised that such platform specific compiler flags have to be
> manually maintained by out of the kernel tree modules developers.
You don't, Kbuild should do it transprently for you.
It's possible you're simply not using kbuild correctly
for external module builds, or something in your Makefile
is overriding the arch specific CFLAGS.
David Miller
Date: Tue, 22 Jun 2010 21:35:30 +0200
> Most of your Makefile looks fine - I guess we need to find the bug
> in the build environmnet and not in the Makefile.
Sam, note that these guys are working with 2.6.26 or some
ancient kernel like that :-/