Messages in this thread | | | Date | Sun, 1 Sep 2019 11:36:45 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH 0/4] objtool,perf: Use shared x86 insn decoder |
| |
On Sat, 31 Aug 2019 17:19:31 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Sat, Aug 31, 2019 at 10:51:52AM +0900, Masami Hiramatsu escreveu: > > 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. > > Ok, I'm in a hurry right now, plumbers and all, so I'll just add the > diff -I trick and will have your "I would like that trick" sentence > above as an Acked-by: you, ok?
Yes, that's fine :) Please use my acked-by for the diff -I trick patch.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you,
> > - Arnaldo > > > > > > 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> > > -- > > - Arnaldo
-- Masami Hiramatsu <mhiramat@kernel.org>
| |