search for: iovisor

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > This same value for EM_BPF is being propagated to glibc, > elfutils, and binutils. great! Can you share the link to glibc and the other patches? > diff --git a/include/llvm/Support/ELF.h b/include/llvm/Support/ELF.h > index 352fd8a...

On 06/16/2016 06:57 PM, Richard Henderson via iovisor-dev wrote: > On 06/15/2016 10:14 PM, Alexei Starovoitov wrote: >> On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev >> <iovisor-dev at lists.iovisor.org> wrote: >>> This same value for EM_BPF is being propagated to glibc, >>> elfutils, and bin...

On Sat, Sep 23, 2017 at 1:41 AM, Jakub Kicinski via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > On Fri, 22 Sep 2017 22:03:47 -0700, Yonghong Song wrote: >> On 9/22/17 9:24 AM, Jakub Kicinski wrote: >> > On Thu, 21 Sep 2017 11:56:55 -0700, Alexei Starovoitov wrote: >> >> On Wed, Sep 20, 2017 at 12:20:40AM +0100...

...d 32bit architecture! I am not an expert in LLVM tablegen. I briefly looked through the code change and it looks like correct. Hopefully some llvm-dev tablegen experts can comment on the implementation. Below I only have a couple of minor comments. On Mon, Sep 18, 2017 at 1:47 PM, Jiong Wang via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > This patch introduce the new "w*" 32-bit register set and alias them to the low > 32-bit of the corresponding 64-bit register. > > Acked-by: Jakub Kicinski <jakub.kicinski at netronome.com> > Signed-off-by: Jiong W...

On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: > On 18/09/2017 22:29, Daniel Borkmann wrote: > > On 09/18/2017 10:47 PM, Jiong Wang wrote: > > > Hi, > > > > > >    Currently, LLVM eBPF backend always generate code in 64-bit mode, > > > this may > > > cause troubles when JITing to...

Hi, Jiong, The new patch looks good. I did some basic testing on net-next:samples/bpf and net-next:tools/testing/selftests/bpf and it works fine. All existing llvm unit tests are not impacted as well as expected. I have applied the patch to the trunk. Besides your other work to support 32bit abi, it would be interesting to see how new 32bit register can be used in 64bit architecture which may

On Sat, Sep 23, 2017 at 10:41:25AM +0200, Jakub Kicinski wrote: > > > Thinking about next steps - do we expect the 32b operations to clear the > > > upper halves of the registers? The interpreter does it, and so does > > > x86. I don't think we can load 32bit-only programs on 64bit hosts, so > > > we would need some form of data flow analysis in the kernel

On 2015/8/4 3:44, Alexei Starovoitov wrote: [SNIP] >> I'll post 2 LLVM patches by replying this mail. Please have a look and >> help me >> send them to LLVM if you think my code is correct. > > [SNIP] > patch 2: > do we really need to hack clang? > Can you just define a function that aliases to intrinsic, > like we do for ld_abs/ld_ind ? > void

...programs who try to update it in the verifier > check_map_func_compatibility. > > if you know of any case where devmap needs to be updated from the BPF > program please let me know. Did we find a solution to non-map redirect? Sorry if I missed the discussion, I couldn't make the iovisor call this week due to travel.

...lt;6a> DW_AT_decl_file : 1 <6b> DW_AT_decl_line : 29 <6c> DW_AT_type : <0x72> then from DW_AT_name and DW_AT_const_value we can do the mapping. Drawback is that all __typeinfo_ prefixed names become reserved. > btw, if you haven't looked at iovisor/bcc, there we're solving > similar problem differently. There we use clang rewriter, so all > structs fields are visible at this level, then we use bpf backend > in JIT mode and push bpf instructions into the kernel on the fly > completely skipping ELF and .o > For example in: &g...