Build failure triggered by recordmcount

Build failure triggered by recordmcount

[Arnaud Lacombe]

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/

Re: Build failure triggered by recordmcount

[wu zhangjin]

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/
>
>

Re: Build failure triggered by recordmcount

[wu zhangjin]

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/
>>
>>
>

Re: Build failure triggered by recordmcount

[wu zhangjin]

(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/
>>>
>>>
>>
>

Re: Build failure triggered by recordmcount

[wu zhangjin]

(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/
>>>
>>>
>>
>

Re: Build failure triggered by recordmcount

[Arnaud Lacombe]

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

Re: Build failure triggered by recordmcount

[John Reiser]

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


-- 

Re: Build failure triggered by recordmcount

[wu zhangjin]

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
>
>
> --
>

Re: Build failure triggered by recordmcount

[wu zhangjin]

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

Re: Build failure triggered by recordmcount

[Steven Rostedt]

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
> 
> 

Re: Build failure triggered by recordmcount

[Arnaud Lacombe]

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 ?

Re: Build failure triggered by recordmcount

[wu zhangjin]

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
>>
>>
>
>
>

Re: Build failure triggered by recordmcount

[Ralf Baechle]

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

Re: Build failure triggered by recordmcount

[Arnaud Lacombe]

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

Re: Build failure triggered by recordmcount

[Sergei Shtylyov]

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

Re: Build failure triggered by recordmcount

[Steven Rostedt]

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

Re: Build failure triggered by recordmcount

[John Reiser]

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>

-- 

Re: Build failure triggered by recordmcount

[Ralf Baechle]

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

Re: Build failure triggered by recordmcount

[Ralf Baechle]

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

Re: Build failure triggered by recordmcount

[Steven Rostedt]

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