similar to: Wrapping lit commands for device testing

Hello George, I would be very much interested in a (generic) solution that would allow running tests on a remote host/device. My intended use case for this is lldb+android, and I am mostly interested in googletest-style tests. In fact, I proposed something vaguely similar to this (but limited to gtest) last year <http://lists.llvm.org/pipermail/llvm-dev/2017-May/113370.html>. However, due

Hi Pavel, I was thinking about a generic proposal for a while, but then I’ve realized that a much simpler heuristic suffices for all of my needs: - Prepend all commands which should execute on the device with %run, which runs a wrapper python script - Inside that script use a simple regexp to find all paths - sync all paths to the device - run the executable on the device - sync all paths

Dan/Daniel/Eric, I'm testing a bare-metal ARM toolchain, and I've hacked up my local copy of lit to get it to run libcxx tests on qemu. I wanted to pick your collective brains to see if there was a better way of doing this. What I have implemented is here (don't take this as a formal review request, we can do that later once we figure out the best direction to go): lit part:

If running ASan on the host architecture, we can symbolize output with: export LLVM_SYMBOLIZER_PATH=`which llvm-symbolizer` ./myInstrumentedProgram but on Android symbolizing is more complex. The bash script below is a "hello world" for symbolizing ASan output on Android. Is there a simpler way to do this? # Execute the test and save its output adb push

On Wed, Jul 12, 2017 at 11:54 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > On Jul 12, 2017, at 11:34 AM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov <ekarpenkov at apple.com> > wrote: > >> >> On Jul 12, 2017, at 11:01 AM, Kostya Serebryany <kcc at google.com> wrote:

+ Chandler, Danny, We are considering to move the libFuzzer code from llvm to compiler-rt, and that implies a license change. Will it be sufficient to do the following? * e-mail to all contributors (a short list, below) asking for their consent * remove any code for which we did not get consent in, say, 1 week. (BTW, this list is actually much shorter, I recognize many of these as belonging

On Wed, Oct 30, 2013 at 2:08 PM, Greg Fitzgerald <garious at gmail.com> wrote: > If running ASan on the host architecture, we can symbolize output with: > > export LLVM_SYMBOLIZER_PATH=`which llvm-symbolizer` > ./myInstrumentedProgram > > but on Android symbolizing is more complex. The bash script below is > a "hello world" for symbolizing ASan output

On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > On Jul 12, 2017, at 11:01 AM, Kostya Serebryany <kcc at google.com> wrote: > One question: will it make sense to *copy* the code to the new location, > work on it, then delete the code from the old location, > instead of doing a move in a single commit? > I don't expect any

> On Jul 17, 2017, at 2:06 PM, Daniel Berlin <dannyb at google.com> wrote: > > This process works legally, but i can't speak to whether the foundation would be okay with it, as it may result in bad press, etc, if you rip code out. Thank you for your reply! I have two additional questions: 1) Why is it ripping the code out if compiler-rt is still part of LLVM? 2) Does it mean

On Tue, Jul 11, 2017 at 7:02 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > I’ve submitted a WIP PR: https://reviews.llvm.org/D35288 > Thanks for working in this! One question: will it make sense to *copy* the code to the new location, work on it, then delete the code from the old location, instead of doing a move in a single commit? I don't expect any dramatic changes

Thanks for letting me know that this is in the works. This is something that would make running ASan (and all other sanitizers I assume) quite a bit more appealing on Android. If there's anything I can do to help, please let me know. If you'd like to discuss in person, I'll be at the Developers' Meeting next week. -Greg On Thu, Oct 31, 2013 at 1:58 PM, Alexey Samsonov

> On May 10, 2017, at 4:43 PM, George Karpenkov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Actually, there’s another problem we have missed: libraries under `build/lib` are not installed into toolchain > on mac os (and neither on linux, I would suppose). Actually that isn't accurate. By default we don't install the LLVM libraries, but that is completely

> Does %run support ssh-based testing? Yes, %run is configured by the user. I configure it to call a shell script that calls qemu-arm. It could just as easily ssh or "adb push && adb shell". -Greg On Wed, Apr 16, 2014 at 11:44 PM, Yury Gribov <y.gribov at samsung.com> wrote: > Greg, > > >> Clever, but I hope we can try to avoid the symlink hackery.

Hi there Firstly I must claim that this is the first time I using a mailing list and I am not familiar with the rules here. As well I am not so good at English too. So here's my apologizes if I'm not able to claim the problem clearly. I'm now using CentOS 6.3 with kernel 2.6.32-279.19.1.el668. Recently I wanna transfer my work from WIndows 8 to Linux. One of my hobbies is developing

You are citing the "Android platform workflow" section, which is about sanitizing components of the Android system itself. For NDK apps, see "Android NDK workflow" in the same document. You need -eng build because preloading libraries into dalvik vm is not allowed in user builds. JellyBean includes several bugfixes in the dynamic loader that asan needs. Was there any useful

Hi, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have tried to compile llvm-mc-assemble-fuzzer, and llvm-mc-disassemble-fuzzer, and I couldn’t build either of those. For the first one, the reason is that it refers to a nonexistent enum, and for the second one I believe the reason is that it

> On May 9, 2017, at 3:00 PM, Kostya Serebryany <kcc at google.com> wrote: > > Thanks for the explanations! (it was worth asking) > > I do want to build libFuzzer itself (and its tests) using the just-built clang. So, llvm/runtimes then. > I'd name the directory llvm/runtimes/libFuzzer, if possible (the old path was lib/Fuzzer which is how the tool got it's

Hi All, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have looked into tools/llvm-pdbutil, and “ninja llvm-pdbutil-fuzzer” does not build at all, and the error refers to non-existent headers. The last update to the codebase is reasonably recent, and was done in June 2017. Is anyone using it?

Hi All, Currently libfuzzer depends on (often freshly built) clang, yet the dependency is not explicitly specified in cmake. That leads to various issues: for instance, it’s not possible to check out LLVM repo and run libfuzzer tests: one would often need to compile fresh clang first, and then create a separate build directory, where libfuzzer could be tested. For the buildbot this problem is

> I really like the property of libFuzzer living in its own place so that > it's easy to use without building the world But it’s not: the implementation of the coverage instrumentation is done in one of the sanitizers, so it’s impossible to just use libFuzzer without them. Furthermore, I would think that almost all libFuzzer users would use a sanitizer while fuzzing. I can see a few