* Re: Build failure triggered by recordmcount
2010-11-22 14:57 ` wu zhangjin
@ 2010-11-22 15:00 ` wu zhangjin
2010-11-22 15:00 ` wu zhangjin
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: wu zhangjin @ 2010-11-22 15:00 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Steven Rostedt, linux-mips
(Change the wrong Email address jreiseer@bitwagon.com to jreiser@BitWagon.com)
On Mon, Nov 22, 2010 at 10:57 PM, wu zhangjin <wuzhangjin@gmail.com> wrote:
> Hi,
>
> The cause should be the endian problem, I guess you were cross-compiling it?
>
> If we compile the kernel for (32bit + big endian) target on an x86
> machine(little endian) or reversely, then, it will fail.
>
> Since the scripts/recordmcount is compiled with the local toolchain,
> the data structs will be explained according to the local
> configuration(endian...).
>
> So, we may need to custom our own elf.h for recordmcount according to
> the target type(endian here) of the kernel image:
>
> At first, pass the target information to recordmcount(only a demo
> here, we may need to clear it carefully):
>
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 2e08810..151fe3e 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -11,6 +11,9 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
> hostprogs-$(CONFIG_LOGO) += pnmtologo
> hostprogs-$(CONFIG_VT) += conmakehash
> hostprogs-$(CONFIG_IKCONFIG) += bin2c
> +HOSTCFLAGS_recordmcount.o += -DARCH=__$(ARCH)__ \
> + -DBIT=__$(if $(CONFIG_64BIT),64,32)__ \
> + -DENDIAN=__$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)__
> hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
>
> always := $(hostprogs-y) $(hostprogs-m)
>
> Then, custom the related data struct(Elf...) for the specific
> target(Perhaps we can steal some code from glibc...) and as a result,
> no need to check the targets at run-time... just like what we have
> done for the Perl version of recordmcount, but for the C version of
> recordmcount, we only need to pass the information for one time.
>
> Regard,
> Wu Zhangjin
>
> On Mon, Nov 22, 2010 at 7:42 PM, wu zhangjin <wuzhangjin@gmail.com> wrote:
>> Hi, Arnaud
>>
>> This only happen at 32bit + big endian, so, perhaps, the symbol
>> reltype of bitendian 32bit differs from little endian 32bit, I will
>> check it later, thanks!
>>
>> Regards,
>> Wu Zhangjin
>>
>> On Mon, Nov 22, 2010 at 11:04 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> Hi,
>>>
>>> The build of an `allyesconfig' configuration from v2.6.37-rc3 is
>>> failing relatively soon on the following:
>>>
>>> [...]
>>> LD init/mounts.o
>>> /OpenWrt-SDK-ar71xx-for-Linux-i686/staging_dir/toolchain-mips_gcc4.1.2/bin/mips-linux-ld:
>>> init/do_mounts.o: bad reloc symbol index (0x20200 >= 0x84) for offset
>>> 0x0 in section `__mcount_loc'
>>>
>>> /OpenWrt-SDK-ar71xx-for-Linux-i686/staging_dir/toolchain-mips_gcc4.1.2/bin/mips-linux-ld
>>> -v
>>> GNU ld version 2.17
>>>
>>> The toolchain originated from OpenWRT Kamikaze and is available on their FTP[0].
>>>
>>> I've not been able to locate the exact point of failure.
>>>
>>> - Arnaud
>>>
>>> [0]: http://downloads.openwrt.org/kamikaze/8.09.2/ar71xx/
>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-11-22 14:57 ` wu zhangjin
2010-11-22 15:00 ` wu zhangjin
@ 2010-11-22 15:00 ` wu zhangjin
2010-11-22 18:46 ` Arnaud Lacombe
2010-12-02 15:15 ` Ralf Baechle
3 siblings, 0 replies; 20+ messages in thread
From: wu zhangjin @ 2010-11-22 15:00 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: John Reiser, Steven Rostedt, linux-mips
(Change the wrong Email address jreiseer@bitwagon.com to jreiser@BitWagon.com)
On Mon, Nov 22, 2010 at 10:57 PM, wu zhangjin <wuzhangjin@gmail.com> wrote:
> Hi,
>
> The cause should be the endian problem, I guess you were cross-compiling it?
>
> If we compile the kernel for (32bit + big endian) target on an x86
> machine(little endian) or reversely, then, it will fail.
>
> Since the scripts/recordmcount is compiled with the local toolchain,
> the data structs will be explained according to the local
> configuration(endian...).
>
> So, we may need to custom our own elf.h for recordmcount according to
> the target type(endian here) of the kernel image:
>
> At first, pass the target information to recordmcount(only a demo
> here, we may need to clear it carefully):
>
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 2e08810..151fe3e 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -11,6 +11,9 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
> hostprogs-$(CONFIG_LOGO) += pnmtologo
> hostprogs-$(CONFIG_VT) += conmakehash
> hostprogs-$(CONFIG_IKCONFIG) += bin2c
> +HOSTCFLAGS_recordmcount.o += -DARCH=__$(ARCH)__ \
> + -DBIT=__$(if $(CONFIG_64BIT),64,32)__ \
> + -DENDIAN=__$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)__
> hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
>
> always := $(hostprogs-y) $(hostprogs-m)
>
> Then, custom the related data struct(Elf...) for the specific
> target(Perhaps we can steal some code from glibc...) and as a result,
> no need to check the targets at run-time... just like what we have
> done for the Perl version of recordmcount, but for the C version of
> recordmcount, we only need to pass the information for one time.
>
> Regard,
> Wu Zhangjin
>
> On Mon, Nov 22, 2010 at 7:42 PM, wu zhangjin <wuzhangjin@gmail.com> wrote:
>> Hi, Arnaud
>>
>> This only happen at 32bit + big endian, so, perhaps, the symbol
>> reltype of bitendian 32bit differs from little endian 32bit, I will
>> check it later, thanks!
>>
>> Regards,
>> Wu Zhangjin
>>
>> On Mon, Nov 22, 2010 at 11:04 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> Hi,
>>>
>>> The build of an `allyesconfig' configuration from v2.6.37-rc3 is
>>> failing relatively soon on the following:
>>>
>>> [...]
>>> LD init/mounts.o
>>> /OpenWrt-SDK-ar71xx-for-Linux-i686/staging_dir/toolchain-mips_gcc4.1.2/bin/mips-linux-ld:
>>> init/do_mounts.o: bad reloc symbol index (0x20200 >= 0x84) for offset
>>> 0x0 in section `__mcount_loc'
>>>
>>> /OpenWrt-SDK-ar71xx-for-Linux-i686/staging_dir/toolchain-mips_gcc4.1.2/bin/mips-linux-ld
>>> -v
>>> GNU ld version 2.17
>>>
>>> The toolchain originated from OpenWRT Kamikaze and is available on their FTP[0].
>>>
>>> I've not been able to locate the exact point of failure.
>>>
>>> - Arnaud
>>>
>>> [0]: http://downloads.openwrt.org/kamikaze/8.09.2/ar71xx/
>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Build failure triggered by recordmcount
2010-11-22 14:57 ` wu zhangjin
2010-11-22 15:00 ` wu zhangjin
2010-11-22 15:00 ` wu zhangjin
@ 2010-11-22 18:46 ` Arnaud Lacombe
2010-11-23 3:41 ` John Reiser
` (2 more replies)
2010-12-02 15:15 ` Ralf Baechle
3 siblings, 3 replies; 20+ messages in thread
From: Arnaud Lacombe @ 2010-11-22 18:46 UTC (permalink / raw)
To: wu zhangjin; +Cc: John Reiser, Steven Rostedt, linux-mips
Hi,
On Mon, Nov 22, 2010 at 9:57 AM, wu zhangjin <wuzhangjin@gmail.com> wrote:
> Hi,
>
> The cause should be the endian problem, I guess you were cross-compiling it?
>
yes.
> If we compile the kernel for (32bit + big endian) target on an x86
> machine(little endian) or reversely, then, it will fail.
>
> Since the scripts/recordmcount is compiled with the local toolchain,
> the data structs will be explained according to the local
> configuration(endian...).
>
will it ? recordmcount.c does not switch endianness based on the host,
but based on format of the object file, see the switch
(ehdr->e_ident[EI_DATA]) { ... } in do_file(), the result does also
depend a runtime endianness check.
> So, we may need to custom our own elf.h for recordmcount according to
> the target type(endian here) of the kernel image:
>
> At first, pass the target information to recordmcount(only a demo
> here, we may need to clear it carefully):
>
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 2e08810..151fe3e 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -11,6 +11,9 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
> hostprogs-$(CONFIG_LOGO) += pnmtologo
> hostprogs-$(CONFIG_VT) += conmakehash
> hostprogs-$(CONFIG_IKCONFIG) += bin2c
> +HOSTCFLAGS_recordmcount.o += -DARCH=__$(ARCH)__ \
> + -DBIT=__$(if $(CONFIG_64BIT),64,32)__ \
> + -DENDIAN=__$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)__
> hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
>
> always := $(hostprogs-y) $(hostprogs-m)
>
hum,
% grep "BIT\|ENDIAN" scripts/recordmcount.*
scripts/recordmcount.h: mcsec.sh_type = w(SHT_PROGBITS);
scripts/recordmcount.h: if (SHT_PROGBITS != w(txthdr->sh_type) ||
so none these macro are not checked explicitly, and headers included
should not either.
- Arnaud
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-11-22 18:46 ` Arnaud Lacombe
@ 2010-11-23 3:41 ` John Reiser
2010-11-23 4:56 ` wu zhangjin
` (2 more replies)
2010-11-23 5:20 ` wu zhangjin
2010-12-02 14:54 ` Ralf Baechle
2 siblings, 3 replies; 20+ messages in thread
From: John Reiser @ 2010-11-23 3:41 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Steven Rostedt, linux-mips, wu zhangjin
It looks to me like the change which introduced "virtual functions"
forgot about cross-platform endianness. Can anyone please test this patch?
Thank you to Arnaud for supplying before+after data files do_mounts*.o.
recordmcount: Honor endianness in fn_ELF_R_INFO
---
scripts/recordmcount.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index 58e933a..3966717 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -119,7 +119,7 @@ static uint_t (*Elf_r_sym)(Elf_Rel const *rp) = fn_ELF_R_SYM;
static void fn_ELF_R_INFO(Elf_Rel *const rp, unsigned sym, unsigned type)
{
- rp->r_info = ELF_R_INFO(sym, type);
+ rp->r_info = _w(ELF_R_INFO(sym, type));
}
static void (*Elf_r_info)(Elf_Rel *const rp, unsigned sym, unsigned type) = fn_ELF_R_INFO;
-- 1.7.3.2
--
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-11-23 3:41 ` John Reiser
@ 2010-11-23 4:56 ` wu zhangjin
2010-11-23 17:09 ` Steven Rostedt
2010-12-02 4:54 ` Arnaud Lacombe
2 siblings, 0 replies; 20+ messages in thread
From: wu zhangjin @ 2010-11-23 4:56 UTC (permalink / raw)
To: John Reiser; +Cc: Arnaud Lacombe, Steven Rostedt, linux-mips
This does solve the problem, now we get the right result:
$ readelf -a init/do_mounts.o
Relocation section '.rel__mcount_loc' at offset 0x2f60 contains 2 entries:
Offset Info Type Sym.Value Sym. Name
00000000 00000202 R_MIPS_32 00000000 .text
00000004 00000202 R_MIPS_32 00000000 .text
On Tue, Nov 23, 2010 at 11:41 AM, John Reiser <jreiser@bitwagon.com> wrote:
> It looks to me like the change which introduced "virtual functions"
> forgot about cross-platform endianness. Can anyone please test this patch?
> Thank you to Arnaud for supplying before+after data files do_mounts*.o.
>
>
> recordmcount: Honor endianness in fn_ELF_R_INFO
>
> ---
> scripts/recordmcount.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
> index 58e933a..3966717 100644
> --- a/scripts/recordmcount.h
> +++ b/scripts/recordmcount.h
> @@ -119,7 +119,7 @@ static uint_t (*Elf_r_sym)(Elf_Rel const *rp) = fn_ELF_R_SYM;
> static void fn_ELF_R_INFO(Elf_Rel *const rp, unsigned sym, unsigned type)
> {
> - rp->r_info = ELF_R_INFO(sym, type);
> + rp->r_info = _w(ELF_R_INFO(sym, type));
> }
> static void (*Elf_r_info)(Elf_Rel *const rp, unsigned sym, unsigned type) = fn_ELF_R_INFO;
> -- 1.7.3.2
>
>
> --
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-11-23 3:41 ` John Reiser
2010-11-23 4:56 ` wu zhangjin
@ 2010-11-23 17:09 ` Steven Rostedt
2010-11-23 20:09 ` Arnaud Lacombe
2010-11-24 9:26 ` wu zhangjin
2010-12-02 4:54 ` Arnaud Lacombe
2 siblings, 2 replies; 20+ messages in thread
From: Steven Rostedt @ 2010-11-23 17:09 UTC (permalink / raw)
To: John Reiser; +Cc: Arnaud Lacombe, linux-mips, wu zhangjin
On Mon, 2010-11-22 at 19:41 -0800, John Reiser wrote:
> It looks to me like the change which introduced "virtual functions"
> forgot about cross-platform endianness. Can anyone please test this patch?
> Thank you to Arnaud for supplying before+after data files do_mounts*.o.
>
>
> recordmcount: Honor endianness in fn_ELF_R_INFO
Arnaud, can I get a "Tested-by" from you.
Wu, can you give me your Acked-by:
Thanks,
-- Steve
>
> ---
> scripts/recordmcount.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
> index 58e933a..3966717 100644
> --- a/scripts/recordmcount.h
> +++ b/scripts/recordmcount.h
> @@ -119,7 +119,7 @@ static uint_t (*Elf_r_sym)(Elf_Rel const *rp) = fn_ELF_R_SYM;
> static void fn_ELF_R_INFO(Elf_Rel *const rp, unsigned sym, unsigned type)
> {
> - rp->r_info = ELF_R_INFO(sym, type);
> + rp->r_info = _w(ELF_R_INFO(sym, type));
> }
> static void (*Elf_r_info)(Elf_Rel *const rp, unsigned sym, unsigned type) = fn_ELF_R_INFO;
> -- 1.7.3.2
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-11-23 17:09 ` Steven Rostedt
@ 2010-11-23 20:09 ` Arnaud Lacombe
2010-12-01 13:47 ` Ralf Baechle
2010-11-24 9:26 ` wu zhangjin
1 sibling, 1 reply; 20+ messages in thread
From: Arnaud Lacombe @ 2010-11-23 20:09 UTC (permalink / raw)
To: Steven Rostedt; +Cc: John Reiser, linux-mips, wu zhangjin
Hi,
On Tue, Nov 23, 2010 at 12:09 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 2010-11-22 at 19:41 -0800, John Reiser wrote:
>> It looks to me like the change which introduced "virtual functions"
>> forgot about cross-platform endianness. Can anyone please test this patch?
>> Thank you to Arnaud for supplying before+after data files do_mounts*.o.
>>
>>
>> recordmcount: Honor endianness in fn_ELF_R_INFO
>
> Arnaud, can I get a "Tested-by" from you.
>
allyesconfig kept building for +1h30 or so, until some unrelated
SoundBlaster16 ioctl size check issue[0], with manual application of
John's patch. I'll restart a full build tonight, in the mean time, I
guess we can assume it is fixed.
Reported-by: Arnaud Lacombe <lacombar@gmail.com>
Tested-by: Arnaud Lacombe <lacombar@gmail.com>
Thanks John!
- Arnaud
[0] Ralf, is there any specific reason mips keeps defining its own
_IOC_SIZEBITS ?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Build failure triggered by recordmcount
2010-11-23 20:09 ` Arnaud Lacombe
@ 2010-12-01 13:47 ` Ralf Baechle
0 siblings, 0 replies; 20+ messages in thread
From: Ralf Baechle @ 2010-12-01 13:47 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Steven Rostedt, John Reiser, linux-mips, wu zhangjin
On Tue, Nov 23, 2010 at 03:09:43PM -0500, Arnaud Lacombe wrote:
> [0] Ralf, is there any specific reason mips keeps defining its own
> _IOC_SIZEBITS ?
History. The ABI once upon a time was meant to be compatible the existing
commercial MIPS UNIX flavours. Today that's just historical baggage.
Ralf
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Build failure triggered by recordmcount
2010-11-23 17:09 ` Steven Rostedt
2010-11-23 20:09 ` Arnaud Lacombe
@ 2010-11-24 9:26 ` wu zhangjin
1 sibling, 0 replies; 20+ messages in thread
From: wu zhangjin @ 2010-11-24 9:26 UTC (permalink / raw)
To: Steven Rostedt; +Cc: John Reiser, Arnaud Lacombe, linux-mips
On Wed, Nov 24, 2010 at 1:09 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 2010-11-22 at 19:41 -0800, John Reiser wrote:
>> It looks to me like the change which introduced "virtual functions"
>> forgot about cross-platform endianness. Can anyone please test this patch?
>> Thank you to Arnaud for supplying before+after data files do_mounts*.o.
>>
>>
>> recordmcount: Honor endianness in fn_ELF_R_INFO
>
> Arnaud, can I get a "Tested-by" from you.
>
> Wu, can you give me your Acked-by:
Acked-by: Wu Zhangjin <wuzhangjin@gmail.com>
Thanks & Regards,
Wu Zhangjin
>
> Thanks,
>
> -- Steve
>
>>
>> ---
>> scripts/recordmcount.h | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
>> index 58e933a..3966717 100644
>> --- a/scripts/recordmcount.h
>> +++ b/scripts/recordmcount.h
>> @@ -119,7 +119,7 @@ static uint_t (*Elf_r_sym)(Elf_Rel const *rp) = fn_ELF_R_SYM;
>> static void fn_ELF_R_INFO(Elf_Rel *const rp, unsigned sym, unsigned type)
>> {
>> - rp->r_info = ELF_R_INFO(sym, type);
>> + rp->r_info = _w(ELF_R_INFO(sym, type));
>> }
>> static void (*Elf_r_info)(Elf_Rel *const rp, unsigned sym, unsigned type) = fn_ELF_R_INFO;
>> -- 1.7.3.2
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Build failure triggered by recordmcount
2010-11-23 3:41 ` John Reiser
2010-11-23 4:56 ` wu zhangjin
2010-11-23 17:09 ` Steven Rostedt
@ 2010-12-02 4:54 ` Arnaud Lacombe
2010-12-02 12:01 ` Sergei Shtylyov
2 siblings, 1 reply; 20+ messages in thread
From: Arnaud Lacombe @ 2010-12-02 4:54 UTC (permalink / raw)
To: John Reiser; +Cc: Steven Rostedt, linux-mips, wu zhangjin
Hi Folks,
On Mon, Nov 22, 2010 at 10:41 PM, John Reiser <jreiser@bitwagon.com> wrote:
> It looks to me like the change which introduced "virtual functions"
> forgot about cross-platform endianness. Can anyone please test this patch?
> Thank you to Arnaud for supplying before+after data files do_mounts*.o.
>
>
> recordmcount: Honor endianness in fn_ELF_R_INFO
>
> ---
> scripts/recordmcount.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
> index 58e933a..3966717 100644
> --- a/scripts/recordmcount.h
> +++ b/scripts/recordmcount.h
> @@ -119,7 +119,7 @@ static uint_t (*Elf_r_sym)(Elf_Rel const *rp) = fn_ELF_R_SYM;
> static void fn_ELF_R_INFO(Elf_Rel *const rp, unsigned sym, unsigned type)
> {
> - rp->r_info = ELF_R_INFO(sym, type);
> + rp->r_info = _w(ELF_R_INFO(sym, type));
> }
> static void (*Elf_r_info)(Elf_Rel *const rp, unsigned sym, unsigned type) = fn_ELF_R_INFO;
> -- 1.7.3.2
>
This patch does not seems to have made its way up to Linus tree, has
it been picked by anyone ?
Thanks,
- Arnaud
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-12-02 4:54 ` Arnaud Lacombe
@ 2010-12-02 12:01 ` Sergei Shtylyov
2010-12-02 12:41 ` Steven Rostedt
2010-12-02 14:38 ` John Reiser
0 siblings, 2 replies; 20+ messages in thread
From: Sergei Shtylyov @ 2010-12-02 12:01 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: John Reiser, Steven Rostedt, linux-mips, wu zhangjin
On 02.12.2010 7:54, Arnaud Lacombe wrote:
>> It looks to me like the change which introduced "virtual functions"
>> forgot about cross-platform endianness. Can anyone please test this patch?
>> Thank you to Arnaud for supplying before+after data files do_mounts*.o.
>> recordmcount: Honor endianness in fn_ELF_R_INFO
>> ---
>> scripts/recordmcount.h | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
>> index 58e933a..3966717 100644
>> --- a/scripts/recordmcount.h
>> +++ b/scripts/recordmcount.h
>> @@ -119,7 +119,7 @@ static uint_t (*Elf_r_sym)(Elf_Rel const *rp) = fn_ELF_R_SYM;
>> static void fn_ELF_R_INFO(Elf_Rel *const rp, unsigned sym, unsigned type)
>> {
>> - rp->r_info = ELF_R_INFO(sym, type);
>> + rp->r_info = _w(ELF_R_INFO(sym, type));
>> }
>> static void (*Elf_r_info)(Elf_Rel *const rp, unsigned sym, unsigned type) = fn_ELF_R_INFO;
>> -- 1.7.3.2
> This patch does not seems to have made its way up to Linus tree, has
> it been picked by anyone ?
It was not signed off, so couldn't be applied.
> Thanks,
> - Arnaud
WBR, Sergei
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-12-02 12:01 ` Sergei Shtylyov
@ 2010-12-02 12:41 ` Steven Rostedt
2010-12-02 14:38 ` John Reiser
1 sibling, 0 replies; 20+ messages in thread
From: Steven Rostedt @ 2010-12-02 12:41 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Arnaud Lacombe, John Reiser, linux-mips, wu zhangjin
On Thu, 2010-12-02 at 15:01 +0300, Sergei Shtylyov wrote:
> > This patch does not seems to have made its way up to Linus tree, has
> > it been picked by anyone ?
I have it queued, but have been working on other things (things that pay
me ;-)
>
> It was not signed off, so couldn't be applied.
You're right! I only had it in the mbox to be queued. I would have
notice this when I pulled it into git.
John, Can you reply with your signed-off-by?
Thanks,
-- Steve
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Build failure triggered by recordmcount
2010-12-02 12:01 ` Sergei Shtylyov
2010-12-02 12:41 ` Steven Rostedt
@ 2010-12-02 14:38 ` John Reiser
1 sibling, 0 replies; 20+ messages in thread
From: John Reiser @ 2010-12-02 14:38 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Sergei Shtylyov, Arnaud Lacombe, linux-mips, wu zhangjin
On 12/02/2010 04:01 AM, Sergei Shtylyov wrote:
> On 02.12.2010 7:54, Arnaud Lacombe wrote:
>
>>> It looks to me like the change which introduced "virtual functions"
>>> forgot about cross-platform endianness. Can anyone please test this
>>> patch?
>>> Thank you to Arnaud for supplying before+after data files do_mounts*.o.
>
>
>>> recordmcount: Honor endianness in fn_ELF_R_INFO
>
>>> ---
>>> scripts/recordmcount.h | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>>> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
>>> index 58e933a..3966717 100644
>>> --- a/scripts/recordmcount.h
>>> +++ b/scripts/recordmcount.h
>>> @@ -119,7 +119,7 @@ static uint_t (*Elf_r_sym)(Elf_Rel const *rp) =
>>> fn_ELF_R_SYM;
>>> static void fn_ELF_R_INFO(Elf_Rel *const rp, unsigned sym, unsigned
>>> type)
>>> {
>>> - rp->r_info = ELF_R_INFO(sym, type);
>>> + rp->r_info = _w(ELF_R_INFO(sym, type));
>>> }
>>> static void (*Elf_r_info)(Elf_Rel *const rp, unsigned sym, unsigned
>>> type) = fn_ELF_R_INFO;
>>> -- 1.7.3.2
>
>> This patch does not seems to have made its way up to Linus tree, has
>> it been picked by anyone ?
>
> It was not signed off, so couldn't be applied.
>
Signed-off-by: John Reiser <jreiser@BitWagon.com>
--
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Build failure triggered by recordmcount
2010-11-22 18:46 ` Arnaud Lacombe
2010-11-23 3:41 ` John Reiser
@ 2010-11-23 5:20 ` wu zhangjin
2010-12-02 14:54 ` Ralf Baechle
2 siblings, 0 replies; 20+ messages in thread
From: wu zhangjin @ 2010-11-23 5:20 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: John Reiser, Steven Rostedt, linux-mips
On Tue, Nov 23, 2010 at 2:46 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Mon, Nov 22, 2010 at 9:57 AM, wu zhangjin <wuzhangjin@gmail.com> wrote:
>> Hi,
>>
>> The cause should be the endian problem, I guess you were cross-compiling it?
>>
> yes.
>
>> If we compile the kernel for (32bit + big endian) target on an x86
>> machine(little endian) or reversely, then, it will fail.
>>
>> Since the scripts/recordmcount is compiled with the local toolchain,
>> the data structs will be explained according to the local
>> configuration(endian...).
>>
> will it ? recordmcount.c does not switch endianness based on the host,
> but based on format of the object file, see the switch
> (ehdr->e_ident[EI_DATA]) { ... } in do_file(), the result does also
> depend a runtime endianness check.
Yes ;-)
>
>> So, we may need to custom our own elf.h for recordmcount according to
>> the target type(endian here) of the kernel image:
>>
>> At first, pass the target information to recordmcount(only a demo
>> here, we may need to clear it carefully):
>>
>> diff --git a/scripts/Makefile b/scripts/Makefile
>> index 2e08810..151fe3e 100644
>> --- a/scripts/Makefile
>> +++ b/scripts/Makefile
>> @@ -11,6 +11,9 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
>> hostprogs-$(CONFIG_LOGO) += pnmtologo
>> hostprogs-$(CONFIG_VT) += conmakehash
>> hostprogs-$(CONFIG_IKCONFIG) += bin2c
>> +HOSTCFLAGS_recordmcount.o += -DARCH=__$(ARCH)__ \
>> + -DBIT=__$(if $(CONFIG_64BIT),64,32)__ \
>> + -DENDIAN=__$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)__
>> hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
>>
>> always := $(hostprogs-y) $(hostprogs-m)
>>
> hum,
>
> % grep "BIT\|ENDIAN" scripts/recordmcount.*
> scripts/recordmcount.h: mcsec.sh_type = w(SHT_PROGBITS);
> scripts/recordmcount.h: if (SHT_PROGBITS != w(txthdr->sh_type) ||
>
> so none these macro are not checked explicitly, and headers included
> should not either.
John have already abstracted w, w2, w8 to handle the endianess
problem, I just forgot looking to them, sorry ;-)
BTW,
1. But check the endianess and ARCH before compiling the
scripts/recordmcount.c may speedup it a lot for after issuing "make
ARCH=XXX", everything including the endianess and ARCH of the object
files are definite, so, we may don't need to check them at runtime. of
course, check them at runtime can avoid compiling it for different
ARCHs but who will use this for different ARCHs at the same time ;-)
2. In the long run, we may be possible to add a new option(with -pg)
to gcc and ask it to create a __mcount_loc section for us, then, we
will be able to use it in kernel directly. I think gcc will be easier
to put the _mcount calling sites into a section because it adds them
and therefore knows 'more'(where, endianess, type... are definite)
about them, but in kernel, we need extra/complex search, check and
relocation...
Thanks & Regards,
Wu Zhangjin
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-11-22 18:46 ` Arnaud Lacombe
2010-11-23 3:41 ` John Reiser
2010-11-23 5:20 ` wu zhangjin
@ 2010-12-02 14:54 ` Ralf Baechle
2010-12-02 15:18 ` Steven Rostedt
2 siblings, 1 reply; 20+ messages in thread
From: Ralf Baechle @ 2010-12-02 14:54 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: wu zhangjin, John Reiser, Steven Rostedt, linux-mips
On Mon, Nov 22, 2010 at 01:46:54PM -0500, Arnaud Lacombe wrote:
> On Mon, Nov 22, 2010 at 9:57 AM, wu zhangjin <wuzhangjin@gmail.com> wrote:
> > Hi,
> >
> > The cause should be the endian problem, I guess you were cross-compiling it?
> >
> yes.
>
> > If we compile the kernel for (32bit + big endian) target on an x86
> > machine(little endian) or reversely, then, it will fail.
> >
> > Since the scripts/recordmcount is compiled with the local toolchain,
> > the data structs will be explained according to the local
> > configuration(endian...).
> >
> will it ? recordmcount.c does not switch endianness based on the host,
> but based on format of the object file, see the switch
> (ehdr->e_ident[EI_DATA]) { ... } in do_file(), the result does also
> depend a runtime endianness check.
>
> > So, we may need to custom our own elf.h for recordmcount according to
> > the target type(endian here) of the kernel image:
> >
> > At first, pass the target information to recordmcount(only a demo
> > here, we may need to clear it carefully):
Looks all right to me. Steven, can you merge it?
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Build failure triggered by recordmcount
2010-12-02 14:54 ` Ralf Baechle
@ 2010-12-02 15:18 ` Steven Rostedt
0 siblings, 0 replies; 20+ messages in thread
From: Steven Rostedt @ 2010-12-02 15:18 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Arnaud Lacombe, wu zhangjin, John Reiser, linux-mips
On Thu, 2010-12-02 at 14:54 +0000, Ralf Baechle wrote:
> > > So, we may need to custom our own elf.h for recordmcount according
> to
> > > the target type(endian here) of the kernel image:
> > >
> > > At first, pass the target information to recordmcount(only a demo
> > > here, we may need to clear it carefully):
>
> Looks all right to me. Steven, can you merge it?
>
> Acked-by: Ralf Baechle <ralf@linux-mips.org>
>
Will do, thanks!
-- Steve
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Build failure triggered by recordmcount
2010-11-22 14:57 ` wu zhangjin
` (2 preceding siblings ...)
2010-11-22 18:46 ` Arnaud Lacombe
@ 2010-12-02 15:15 ` Ralf Baechle
3 siblings, 0 replies; 20+ messages in thread
From: Ralf Baechle @ 2010-12-02 15:15 UTC (permalink / raw)
To: wu zhangjin; +Cc: Arnaud Lacombe, John Reiser, Steven Rostedt, linux-mips
On Mon, Nov 22, 2010 at 10:57:40PM +0800, wu zhangjin wrote:
> The cause should be the endian problem, I guess you were cross-compiling it?
>
> If we compile the kernel for (32bit + big endian) target on an x86
> machine(little endian) or reversely, then, it will fail.
>
> Since the scripts/recordmcount is compiled with the local toolchain,
> the data structs will be explained according to the local
> configuration(endian...).
>
> So, we may need to custom our own elf.h for recordmcount according to
> the target type(endian here) of the kernel image:
>
> At first, pass the target information to recordmcount(only a demo
> here, we may need to clear it carefully):
>
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 2e08810..151fe3e 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -11,6 +11,9 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
> hostprogs-$(CONFIG_LOGO) += pnmtologo
> hostprogs-$(CONFIG_VT) += conmakehash
> hostprogs-$(CONFIG_IKCONFIG) += bin2c
> +HOSTCFLAGS_recordmcount.o += -DARCH=__$(ARCH)__ \
> + -DBIT=__$(if $(CONFIG_64BIT),64,32)__ \
> + -DENDIAN=__$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)__
> hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
>
> always := $(hostprogs-y) $(hostprogs-m)
FYI, dropping this one from the patchworks queue then as John's patch seems
to be the right thing.
Ralf
^ permalink raw reply [flat|nested] 20+ messages in thread