lkml.org 
[lkml]   [2019]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/4] objtool,perf: Use shared x86 insn decoder
    On Fri, 30 Aug 2019 16:48:45 -0300
    Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

    > Em Fri, Aug 30, 2019 at 02:31:09PM -0500, Josh Poimboeuf escreveu:
    > > On Fri, Aug 30, 2019 at 04:00:58PM -0300, Arnaldo Carvalho de Melo wrote:
    > > > I.e. we need to make sure that it always gets the x86 stuff, not
    > > > something that is tied to the host arch, with the patch below we get it
    > > > to work, please take a look.
    > > >
    > > > Probably this should go to the master copy, i.e. to the kernel sources,
    > > > no?

    Interesting approach. Hmm, but I would like "diff -I" trick just
    for short term solution.

    > > >
    > > > That or we'll have to ask the check-headers.sh and objtool sync-check
    > > > (hey, this should be unified, each project could provide just the list
    > > > of things it uses, but I digress) to ignore those lines...
    > > >
    > > > I.e. we want to decode intel_PT traces on other arches, ditto for
    > > > CoreSight (not affected here, but similar concept).
    > > >
    > > > will kick the full container build process now.
    > >
    > > Interesting, I didn't realize other arches would be using it. The patch
    >
    > Yeah, decoding CoreSight (aarch64) hardware traces on x86_64 should be
    > as possible as decoding Intel PT hardware traces on aarch64 :-)
    >
    > > looks good to me.
    > >
    > > Ideally there wouldn't be any differences between the headers, but if
    > > that's unavoidable then I guess we can just use the same 'diff -I' trick
    >
    > I'll go with this now, but...
    >
    > > we were using before in the check script(s).
    >
    > Masami? What do you think of applying the patch to the main kernel
    > sources so that building a decoder for x86 on any other arch becomes
    > possible?

    I think the build of kernel and user-space tools are different especially
    for "include/asm", since user-space tools may want to use all architecture
    features, but kernel needs only the architecture which it runs on.
    Maybe we need a special Makefile entries for the modules which depends
    on architecture dependent parts. e.g.

    x86-objs = insn.o inat.o ...
    arm64-objs = coresight.o ...

    and they should have different -I options ('-I arch/x86/include' or
    '-I arch/arm64/include') for compiling.
    I think this is better and scalable, if you use common (clone) files in
    the kernel tree.

    Thank you,

    --
    Masami Hiramatsu <mhiramat@kernel.org>

    \
     
     \ /
      Last update: 2019-08-31 03:53    [W:3.265 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site