Re: [PATCH] perf: fix building error in x86_64 when dwarf unwind is on.

[Jiri Olsa <jolsa@redhat.com>]

On Mon, Jan 12, 2015 at 12:28:10PM +0900, Namhyung Kim wrote:
> On Mon, Jan 12, 2015 at 10:20:55AM +0800, Wang Nan wrote:
> > From: Namhyung Kim <namhyung@kernel.org>
> > 
> > When build with 'make ARCH=x86' and dwarf unwind is on, there is a
> > compiling error:
> > 
> >    CC       /home/wn/perf/arch/x86/util/unwind-libdw.o
> >    CC       /home/wn/perf/arch/x86/tests/regs_load.o
> >  arch/x86/tests/regs_load.S: Assembler messages:
> >  arch/x86/tests/regs_load.S:65: Error: operand type mismatch for `push'
> >  arch/x86/tests/regs_load.S:72: Error: operand type mismatch for `pop'
> >  make[1]: *** [/home/wn/perf/arch/x86/tests/regs_load.o] Error 1
> >  make[1]: INTERNAL: Exiting with 25 jobserver tokens available; should be 24!
> >  make: *** [all] Error 2
> >  ...
> > 
> > Which is caused by incorrectly undefine macro HAVE_ARCH_X86_64_SUPPORT.
> > 'config/Makefile.arch' tests __x86_64__ only when 'ARCH=x86_64'.
> > However, when building x86_64 kernel, ARCH=x86 is valid and commonly
> > used. Building systems, such as yocto, uses x86_64 compiler with
> > 'ARCH=x86' to build x86_64 perf, which causes mismatching.
> > 
> > As __LP64__ is defined for x86_64 as well, we can consolidate the
> > __x86_64__ check to the __LP64__ check and get rid of the IS_X86_64
> > IMHO.
> > 
> > (This patch is made by Namhyung Kim when replying my v1 patch:
> > 
> > https://lkml.org/lkml/2015/1/7/17
> > 
> > I modified the code to remove dependency on RAW_ARCH:
> > 
> > https://lkml.org/lkml/2015/1/7/865
> > 
> > Namhyung Kim didn't provide his SOB in his original email. I add
> > mine only for my modification.)
> 
> Please feel free to add my SOB to this patch.
> 
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Acked-by: Jiri Olsa <jolsa@kernel.org>

also.. I tried 32bit build on x86_64, but I had to disable python
support explicitly to succeed:

  $ make EXTRA_CFLAGS=-m32 NO_LIBPYTHON=1

seems like 'python-config --cflags' returns -m64, which beats -m32,
and the features code always detects 64bit version, which fails
to link at the end with all the rest 32bit stuff

hopefully some python enthusiast will fix it one day,
anyway it's great the 32bit build works.. sort of ;-)

thanks,
jirka