similar to: [LLVMdev] Contributing a buildbot for the BPF backend

Thank you. Alexei just committed the change to SVN. Regards, Marco Leogrande Sent by a carbon-based life form; hence, it may contain repetitions, inaccuracies, logical fallacies and repetitions. On Wed, Jun 17, 2015 at 2:52 PM, Galina Kistanova <gkistanova at gmail.com> wrote: > LGTM. > Please commit. > > Thanks > > Galina > > On Tue, Jun 16, 2015 at 8:32 PM,

Galina, thanks again for your help. I have cooked a new patch that should make a bit more sense. I have added the new builder under _get_experimental_scheduled_builders(), as the comment above that function suggested me it would be a good idea. :) Does it look a reasonable start? Regards, Marco Leogrande Sent by a carbon-based life form; hence, it may contain repetitions, inaccuracies,

Hello Marco, Welcome aboard! slaves.py keeps the build slaves definitions, builders.py keeps the builders definitions. You have to have both. The steps of adding a new slave is here: http://llvm.org/docs/HowToAddABuilder.html. Please make sure you done the step # 10 before bringing your slave up, otherwise it wouldn't be authorized by the master and will be blacklisted after multiple

On 31 October 2016 at 19:46, Galina Kistanova <gkistanova at gmail.com> wrote: > I applied it and reconfigured the master. Thanks Galina! Marco, the build is complaining about Ninja: http://lab.llvm.org:8011/builders/clang-bpf-build/builds/414/steps/cmake%20stage%201/logs/stdio CMake was unable to find a build program corresponding to "Ninja" Now I remember we used ninja by

Hi Richard, Marco, I noticed that you two are the remaining bot owners using the `getClangBuildFactory` from `ClangBuilder`. All the other bots using that builder have moved to the new `getClangCMakeBuildFactory`, including Windows ones. Given that they do similar functionalities, I'd like to encourage you to move to the new factory, so that we can simplify the builder's code. Thanks!

I have installed ninja and retriggered that build. I will monitor the results to confirm it succeeds. Regards, Marco Leogrande Sent by a carbon-based life form; hence, it may contain repetitions, inaccuracies, logical fallacies and repetitions. On Mon, Oct 31, 2016 at 3:17 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 31 October 2016 at 19:46, Galina Kistanova

Renato, thanks for the heads-up. For clang-bpf-build the change should be trivial since we don't use a fancy configuration. I have attached the patch, please apply if appropriate. Thanks. Regards, Marco Leogrande Sent by a carbon-based life form; hence, it may contain repetitions, inaccuracies, logical fallacies and repetitions. On Mon, Oct 31, 2016 at 5:14 AM, Renato Golin

On 31 October 2016 at 18:56, Marco Leogrande <marcol at plumgrid.com> wrote: > For clang-bpf-build the change should be trivial since we don't use a > fancy configuration. > I have attached the patch, please apply if appropriate. I believe it should just work. Galina, can you give it a try? The build should "just work". :) thanks! --renato

On Thu, Jun 4, 2015 at 5:51 AM, Daniel Sanders <daniel.sanders at imgtec.com> wrote: > Author: dsanders > Date: Thu Jun 4 07:51:20 2015 > New Revision: 239035 > > Include BPF target in CMake builds. > > Modified: > llvm/trunk/CMakeLists.txt > > --- llvm/trunk/CMakeLists.txt (original) > +++ llvm/trunk/CMakeLists.txt Thu Jun 4 07:51:20 2015 > @@

Hi All, I'd like to propose to upgrade BPF backend to first class citizen. Current status of it: - used with linux kernel on x64, arm64, s390 architectures - projects that use it: perf, tc, ovs - there are few front-ends in the works: . one is translating custom language to C and then using clang/llvm . another is generating llvm IR directly . yet another is using clang rewriter to

I applied it and reconfigured the master. Thanks for the heads-up! Thanks Galina On Mon, Oct 31, 2016 at 12:07 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 31 October 2016 at 18:56, Marco Leogrande <marcol at plumgrid.com> wrote: > > For clang-bpf-build the change should be trivial since we don't use a > > fancy configuration. > > I have

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

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

Dear there, I was trying to use clang to cross compile executable directly on my mac to bpf ISA: clang -target bpf-linux-gnu aaa.c But I guess maybe the linker does not support BPF? (with -c clang can generate unlinked objs) Unexpected arch UNREACHABLE executed at llvm/tools/clang/lib/Driver/Tools.cpp:8113 Should I use other linkers to link clang generated BPF objs? Thanks, Xiaochu

Dear there, I wasn't able to generate obj file for bpf using llc: llc -march bpf -filetype=obj foo.bc Anyone knows what is the missing part in their backend? I want to make it work for my project. Thanks, Xiaochu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150802/e0b55467/attachment.html>

Hi Alexei, I haven't tried to run code yet. The clang frontend can generate machine code for bpf but llc does not do the job. When i use : llc -march bpf -filetype=obj arith.bc It has this error message: Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file

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..fb8ff71 100644 > ---

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

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

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