Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: wu zhangjin <wuzhangjin@gmail.com>
Cc: Arnaud Lacombe <lacombar@gmail.com>,
	John Reiser <jreiser@bitwagon.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-mips@linux-mips.org
Subject: Re: Build failure triggered by recordmcount
Date: Thu, 2 Dec 2010 15:15:46 +0000	[thread overview]
Message-ID: <20101202151546.GB7503@linux-mips.org> (raw)
In-Reply-To: <AANLkTikaUxKqsqXKYpETOnWAMuCi5gp30ANux0RQuK6Z@mail.gmail.com>

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

      parent reply	other threads:[~2010-12-02 15:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22  3:04 Build failure triggered by recordmcount Arnaud Lacombe
2010-11-22 11:42 ` wu zhangjin
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
2010-11-23  4:56         ` wu zhangjin
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
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
2010-11-23  5:20       ` wu zhangjin
2010-12-02 14:54       ` Ralf Baechle
2010-12-02 15:18         ` Steven Rostedt
2010-12-02 15:15     ` Ralf Baechle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101202151546.GB7503@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=jreiser@bitwagon.com \
    --cc=lacombar@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=rostedt@goodmis.org \
    --cc=wuzhangjin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox