All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Nan <wangnan0@huawei.com>
To: Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>
Cc: <mingo@redhat.com>, <linux-kernel@vger.kernel.org>,
	<lizefan@huawei.com>, <acme@kernel.org>, <jolsa@kernel.org>
Subject: Re: [PATCH] perf: fix building error in x86_64 when dwarf unwind is on
Date: Wed, 7 Jan 2015 20:28:34 +0800	[thread overview]
Message-ID: <54AD2672.1010009@huawei.com> (raw)
In-Reply-To: <20150107083920.GF6243@krava.brq.redhat.com>

On 2015/1/7 16:39, Jiri Olsa wrote:
> On Wed, Jan 07, 2015 at 02:40:04PM +0900, Namhyung Kim wrote:
>> Hi,
>>
>> On Wed, Jan 07, 2015 at 10:53:52AM +0800, Wang Nan wrote:
>>> Ping...
>>
>> Sorry for long delay.
>>
>>>
>>> On 2014/12/29 16:14, Wang Nan wrote:
>>>> On 2014/12/29 15:56, Namhyung Kim wrote:
>>>>> Hi Wang,
>>>>>
>>>>> (Adding Arnaldo and Jiri to CC)
>>>>>
>>>>> On Sat, Dec 27, 2014 at 09:26:11AM +0800, Wang Nan wrote:
>>>>>> 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,
>>>>>> with 'ARCH=x86', the underlying compile may also be x86_64, which causes
>>>>>> mismatching.
>>>>>
>>>>> Hmm.. how did you compile this?  I guess ARCH=x86 requires -m32 flag
>>>>> to the gcc, did you pass it (like via EXTRA_CFLAGS=-m32)?
>>>>>
>>>>> I'm confused by 'underlying compile may also be x86_64' part..
>>>>>
>>>>
>>>> I hit this problem when building perf with Yocto (https://www.yoctoproject.org/), which
>>>> is a famous building system for embeded system.
>>>>
>>>> When building kernel, we can simply use 'make ARCH=x86' and select 'CONFIG_64BIT'
>>>> in menuconfig to get a x86_64 kernel. As a result, there building framework
>>>> like Yocto doesn't ever consider 'x86_64' as a valid ARCH option. See:
>>>> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-arch.bbclass
>>>> Therefore, when building with such framework, it uses a x86_64 compiler and ARCH=x86.
>>
>> Hmm.. okay.  I think that it should also be checked with the new build
>> system for perf, Jiri? ;)
> 
> yea.. however the config/Makefile still stays as it was
> 
> but whatever change you'll make for Makefile.perf I need
> to transform.. but this one does not seem too massive ;-)
> 
>>
>> Anyway, I cleaned up the code like below.. 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.
>>
>> Thanks,
>> Namhyung
>>
>>
>> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
>> index 67a03a825b3c..eb3e2f3e14b4 100644
>> --- a/tools/perf/Makefile.perf
>> +++ b/tools/perf/Makefile.perf
>> @@ -462,10 +462,12 @@ BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
>>  # Benchmark modules
>>  BUILTIN_OBJS += $(OUTPUT)bench/sched-messaging.o
>>  BUILTIN_OBJS += $(OUTPUT)bench/sched-pipe.o
>> +ifeq ($(ARCH),x86)
>>  ifeq ($(RAW_ARCH),x86_64)
>>  BUILTIN_OBJS += $(OUTPUT)bench/mem-memcpy-x86-64-asm.o
>>  BUILTIN_OBJS += $(OUTPUT)bench/mem-memset-x86-64-asm.o
>>  endif
>> +endif
> 
> isn't the check for x86 superfluous here? the x86_64 check is stronger
> 
> otherwise it looks ok to me.. Wang Nan, could you please check
> if it fixes the issue for you?
> 

Sorry, although Namhyung Kim's patch solves my ARCH=x86 problem, it breaks ARM building:

...
| bench/../../../arch/x86/lib/memcpy_64.S: Assembler messages:
| bench/../../../arch/x86/lib/memcpy_64.S:27: Error: junk at end of line, first unrecognized character is `,'
| bench/../../../arch/x86/lib/memcpy_64.S:29: Error: bad instruction `movq %rdi,%rax'
| bench/../../../arch/x86/lib/memcpy_64.S:30: Error: bad instruction `movq %rdx,%rcx'
| bench/../../../arch/x86/lib/memcpy_64.S:31: Error: bad instruction `shrq $3,%rcx'
| bench/../../../arch/x86/lib/memcpy_64.S:32: Error: bad instruction `andl $7,%edx'
...

It builds x86_64 bench when I corss compiling perf for arm (use ARCH=arm). This is caused by Makefile.perf:

...
BUILTIN_OBJS += $(OUTPUT)bench/sched-pipe.o
ifeq ($(RAW_ARCH),x86_64)
BUILTIN_OBJS += $(OUTPUT)bench/mem-memcpy-x86-64-asm.o
BUILTIN_OBJS += $(OUTPUT)bench/mem-memset-x86-64-asm.o
endif
BUILTIN_OBJS += $(OUTPUT)bench/mem-memcpy.o
...

Which rely on RAW_ARCH, but RAW_ARCH is not a cross-compiling-friendly variable now.

> thanks,
> jirka
> 



  reply	other threads:[~2015-01-07 12:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-27  1:26 [PATCH] perf: fix building error in x86_64 when dwarf unwind is on Wang Nan
2014-12-29  7:56 ` Namhyung Kim
2014-12-29  8:14   ` Wang Nan
2015-01-07  2:53     ` Wang Nan
2015-01-07  5:40       ` Namhyung Kim
2015-01-07  8:39         ` Jiri Olsa
2015-01-07 12:28           ` Wang Nan [this message]
2015-01-07 13:50             ` Namhyung Kim
2015-01-08  1:30               ` Wang Nan
2015-01-08  5:09                 ` Namhyung Kim
2015-01-09 14:43                   ` Jiri Olsa
2015-01-12  2:20                     ` Wang Nan
2015-01-12  3:28                       ` Namhyung Kim
2015-01-12 10:36                         ` Jiri Olsa
2015-01-17 10:10                       ` [tip:perf/urgent] perf tools: Fix " tip-bot for Namhyung Kim
  -- strict thread matches above, loose matches on Subject: below --
2015-02-03 19:58 [PATCH] perf: fix " Christopher Covington
2015-02-03 19:58 ` Christopher Covington

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=54AD2672.1010009@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=acme@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.