similar to: [iovisor-dev] [PATCH, BPF 1/5] BPF: Use a provisional ELF e_machine value

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 binutils. >> >> great! >> Can

Hi, Alexei On 2015/7/30 1:13, Alexei Starovoitov wrote: > On 7/29/15 2:38 AM, He Kuang wrote: >> Hi, Alexei >> >> On 2015/7/28 10:18, Alexei Starovoitov wrote: >>> On 7/25/15 3:04 AM, He Kuang wrote: >>>> I noticed that for 64-bit elf format, the reloc sections have >>>> 'Addend' in the entry, but there's no 'Addend' info

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, Jiong Wang via iovisor-dev wrote:

Hi, Jiong, Thanks for the patch! It is a great start to support 32bit register in BPF. In the past, I have studied a little bit to see whether 32bit register support may reduce the number of unnecessary shifts on x86_64 and improve the performance. Looking through a few bpf programs and it looks like the opportunity is not great, but still nice to have if we have this capability. As you

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 32-bit targets. > > >

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

On 2015/8/12 12:57, Alexei Starovoitov wrote: > On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote: >> Think about a program like this: >> >> struct strA { int a; } >> struct strB { int b; } >> int func() { >> struct strA a; >> struct strB b; >> >> a.a = 1; >> b.b = 2; >>

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

Hello, I’m working on porting llvm to build for 65816, and I wanted to use a value of e_machine for this. I was wondering if there is a process for getting a value reserved. I’ve seen some information but its from many years ago, and seems to be well out of date? Just wanted to ask people who would likely know. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I've been working on ELF object support for the MicroBlaze backend and found that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a patch that makes the 16-bit e_machine value in the ELF header configurable by the target backend. Right now the target backend simply passes the 16-bit value that it would like to use in the ELF header. I have considered a second approach where

On Sat, 9 Feb 2019 00:18:31 +0000, Saeed Mahameed wrote: > On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote: > > On Thu, 2019-02-07 at 19:08 +0000, Saeed Mahameed wrote: > > > > > > So > > > 1) on dev_map_update_elem() we will call > > > dev->dev->ndo_bpf() to notify the device on the intention to > > > start/stop > >

Hi, I stopped into IRC to ask about a problem I've been having using Clang in conjunction with LLD to compile and link for an embedded project on Cortex-M ARM processor. First, I am able to separately compile with a call to clang and link with a call to lld, but I cannot use clang to link using lld using the -fuse-ld=lld flag. I have the output from `clang -v -fuse-ld=lld -target

On 8/4/15 11:51 PM, Wangnan (F) wrote: > void bpf_store_half(void *skb, int off, int val) > asm("llvm.bpf.store.half"); > int func() > { > bpf_store_half(0, 0, 0); > return 0; > } > > Compiled with: > > $ clang -g -target bpf -O2 -S -c test.c > > And get this: > > .text > .globl func > .align

Hi vedant, 1. The definition is from llvm/Supprot/ELF.h. But this machine information(e_machine) is given to compiler at lib/MC/ELFObjectWriter.cpp. I greped the whole llvm project and found that e_machine was assigned at only two files. One was lib/MC/ELFObjectWriter.cpp(there was an comment said “e_machine=target”) and the other was tools/obj2yaml/elf2yaml.cpp(GDB stopped only at the

Hi vedant, 1. First, I think your theory is right that llvm’s object file reading libraries do not “understand” the architecture I’m working on. Since I’m using binutils as assembler which means llvm can only provide asm and object file is provided by biutils. I think these ELF header information is provided by my binutils now, so maybe I have to modify binutils code to provide ELF header

On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote: > > It doesn't work for me at first since in my llvm there's only > llvm.bpf.load.*. > > I think llvm.bpf.store.* belone to some patches you haven't posted yet? nope. only loads have special instructions ld_abs/ld_ind which are represented by these intrinsics. stores, so far, are done via single

Hi vedant, The program didn't pass the checking "OF->getArch() != Triple(Arch).getArch()" loadBinaryFormat in CoverageMappingReader.cpp and returned an error. It's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by "

What would be ideal is to have the alloca instruction be able to allocate memory indifferent address spaces instead of only being in private. Micah > -----Original Message----- > From: Pekka Jääskeläinen [mailto:pekka.jaaskelainen at tut.fi] > Sent: Friday, September 28, 2012 1:17 PM > To: James Molloy > Cc: Villmow, Micah; Carlos Sánchez de La Lama; Ouriel, Boaz; pocl- > devel

Send again since llvmdev is moved to llvm-dev at lists.llvm.org On 2015/8/5 9:58, Wangnan (F) wrote: > > > On 2015/8/4 17:01, Wangnan (F) wrote: >> For people who in llvmdev: >> >> This mail is belong to a thread in linux kernel mailing list, the >> first message >> can be retrived from: >> >> http://lkml.kernel.org/r/55B1535E.8090406 at