From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754208AbbHLNP1 (ORCPT ); Wed, 12 Aug 2015 09:15:27 -0400 Received: from mail-yk0-f182.google.com ([209.85.160.182]:33128 "EHLO mail-yk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750735AbbHLNPZ (ORCPT ); Wed, 12 Aug 2015 09:15:25 -0400 MIME-Version: 1.0 In-Reply-To: <55CAD991.4090002@huawei.com> References: <55B1535E.8090406@plumgrid.com> <55B1AEE9.1080207@plumgrid.com> <55B1BC03.9020708@huawei.com> <55B35F42.70803@huawei.com> <55B6E685.30905@plumgrid.com> <55B89F04.5030304@huawei.com> <55B909B2.2080606@plumgrid.com> <55BB4B8A.5000207@huawei.com> <55BFC4A0.9060100@plumgrid.com> <55CAB0C3.40805@huawei.com> <20150812045704.GA58476@Alexeis-MBP.westell.com> <55CAD991.4090002@huawei.com> From: Brenden Blanco Date: Wed, 12 Aug 2015 06:15:05 -0700 Message-ID: Subject: Re: [llvm-dev] llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event To: "Wangnan (F)" , Alexei Starovoitov Cc: llvm-dev@lists.llvm.org, "linux-kernel@vger.kernel.org" , pi3orama , Alexei Starovoitov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Wangnan, I've been authoring the BCC development, so I'll answer those specific questions. > > > Could you please give us further information about your clang rewriter? > I guess you need a new .so when injecting those code into kernel? The rewriter runs all of its passes in a single process, creating no files on disk and having no external dependencies in terms of toolchain. 1. Entry point: bpf_module_create() - C API call to create module, can take filename or directly a c string with the full contents of the program 2. Convert contents into a clang memory buffer 3. Set up a clang driver::CompilerInvocation in the style of the clang interpreter example 4. Run a rewriter pass over the memory buffer file, annotating and/or doing BPF specific magic on the input source a. Open BPF maps with a call to bpf_create_map directly b. Convert references to map operations with the specific FD of the new map c. Convert arguments to bpf_probe_read calls as needed d. Collect the externed function names to avoid section() hack in the language 5. Re-run the CompilerInvocation on the modified sources 6. JIT the llvm::Module to bpf arch 7. Load the resulting in-memory ".o" to bpf_prog_load, keeping the FD alive in the compiler process 8. Attach the FD as necessary to perf events, socket, tc, etc. 9. goto 1 The above steps are captured in the BCC github repo in src/cc, with the clang specific bits inside of the frontends/clang subdirectory. > I'm not sure. Our target platform should be embedded devices like > smartphone. > Bringing full clang/llvm environment there is not acceptable. The artifact from the build process of BCC is a shared library, which has the clang/llvm .a embedded within them. It is not yet a single binary, but not unfeasible to make it so. The clang toolchain itself does not need to exist on the target. I have not attempted to cross-compile BCC to any architecture, currently x86_64 only. If you have more BCC specific questions not involving clang/llvm, perhaps you can ping Alexei/myself off of the llvm-dev list, in case this discussion is not relevant to them.