Message-ID: <55CC3807.6030401@huawei.com>
Date: Thu, 13 Aug 2015 14:24:07 +0800
From: "Wangnan (F)" <wangnan0@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Brenden Blanco <bblanco@gmail.com>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>
CC: <llvm-dev@lists.llvm.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        pi3orama <pi3orama@163.com>, "Alexei Starovoitov" <ast@plumgrid.com>,
        hekuang 00206996 <hekuang@huawei.com>
Subject: Re: [llvm-dev] llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce
 function for outputing data to perf event
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> <CAH9hs-+Bm_aXSQ4388tR2Rdzt5Erdgj4+ao8OqrV3aEi2G=9Ow@mail.gmail.com>
In-Reply-To: <CAH9hs-+Bm_aXSQ4388tR2Rdzt5Erdgj4+ao8OqrV3aEi2G=9Ow@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2527
Lines: 54

Thank you for your reply.

Add He Kuang to CC list.

On 2015/8/12 21:15, Brenden Blanco wrote:
> 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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/