search for: dberris

...toolchain in step 1, but this time with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`. I get some msan errors, but of this kind instead of the one I'm expecting: ==== $ ./unittests/XRay/XRayTests ==236769==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x70eef8 (/usr/local/google/home/dberris/xray/llvm-project-build-msan/unittests/XRay/XRayTests+0x70eef8) #1 0x70d2dc (/usr/local/google/home/dberris/xray/llvm-project-build-msan/unittests/XRay/XRayTests+0x70d2dc) #2 0x721044 (/usr/local/google/home/dberris/xray/llvm-project-build-msan/unittests/XRay/XRayTests+0x721044) #3 0x6e...

...gt; > > I get some msan errors, but of this kind instead of the one I'm > expecting: > > > > ==== > > $ ./unittests/XRay/XRayTests > > ==236769==WARNING: MemorySanitizer: use-of-uninitialized-value > > #0 0x70eef8 > > > (/usr/local/google/home/dberris/xray/llvm-project-build-msan/unittests/XRay/XRayTests+0x70eef8) > > #1 0x70d2dc > > > (/usr/local/google/home/dberris/xray/llvm-project-build-msan/unittests/XRay/XRayTests+0x70d2dc) > > #2 0x721044 > > > (/usr/local/google/home/dberris/xray/llvm-project-build-m...

...errors, but of this kind instead of the one I'm > expecting: > > > > > > ==== > > > $ ./unittests/XRay/XRayTests > > > ==236769==WARNING: MemorySanitizer: use-of-uninitialized-value > > > #0 0x70eef8 > > > > (/usr/local/google/home/dberris/xray/llvm-project-build-msan/unittests/XRay/XRayTests+0x70eef8) > > > #1 0x70d2dc > > > > (/usr/local/google/home/dberris/xray/llvm-project-build-msan/unittests/XRay/XRayTests+0x70d2dc) > > > #2 0x721044 > > > > (/usr/local/google/home/dberris/xray/...

...to an executable with clang (patched with http://reviews.llvm.org/D20352 and compiler-rt patched with http://reviews.llvm.org/D21612) on Linux, I'm getting something different. Here's a sample of the transcript, and what I'm seeing: --->8 clang invocation 8<--- [16-06-23 3:33:42] dberris at dberris: ~/xray/llvm-build% ./bin/clang -fxray-instrument -x c++ -std=c++11 -o test.bin test.cc -g --verbose clang version 3.9.0 (http://llvm.org/git/clang.git 3ae26ac8b1c9c5db65f3dc0236139448b8b0520a) (http://llvm.org/git/llvm.git 8fd5dd6aa8a633eeb03b245cd0060479371fc521) Target: x86_64-unknown...

...Ray may need to live in a central location, but since the changes to the LLVM pieces are currently in three different places, are there suggestions for where the docs should live? Cheers PS. An example log of how to use XRay with clang+llvm+compiler-rt with the above patches: [16-06-28 17:21:02] dberris at dberris: ~/xray/llvm-build% cat test.cc #include <cstdio> #include <cassert> [[clang::xray_always_instrument]] void foo() { std::printf("Hello, XRay!\n"); } [[clang::xray_never_instrument]] void bar() { std::printf("Not instrumented\n"); } extern void baz(); /...

....byte 0xeb, 0x09' and that allowed the jump instruction to bypass the relaxation, so that fixes my immediate problem. The question still stands though whether it should be possible to do through the instruction builder interface. Cheers On Wed, Jun 22, 2016 at 10:40 AM Dean Michael Berris <dberris at google.com> wrote: > Thanks Nirav, > > I can confirm that this works when I do the compile with llc, but then > when linking to an executable with clang (patched with > http://reviews.llvm.org/D20352 and compiler-rt patched with > http://reviews.llvm.org/D21612) on Linux, I...

...? In any case, the issue appears to be that llvm doesn't realize that the target address is resolved and erroneously applies branch relaxation to the jump. I don't know why a linker private symbol would make a difference. -Nirav On Wed, Jun 22, 2016 at 12:14 PM, Dean Michael Berris <dberris at google.com> wrote: > On Wed, Jun 22, 2016 at 6:05 AM Nirav Davé <niravd at google.com> wrote: > >> This appears to work: >> >> auto Target = OutContext.createLinkerPrivateTempSymbol(); >> >> with >> >> auto Target = OutContext.createTempS...

On Wed, Jun 22, 2016 at 6:05 AM Nirav Davé <niravd at google.com> wrote: > This appears to work: > > auto Target = OutContext.createLinkerPrivateTempSymbol(); > > with > > auto Target = OutContext.createTempSymbol(); > > -Nirav > > Thanks Nirav -- I tried this but I'm still getting a "jmpq <address>" with this incantation when I load and

On 29 June 2016 at 02:49, Dean Michael Berris <dberris at google.com> wrote: > On Wed, Jun 29, 2016 at 12:17 PM Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> On 28 June 2016 at 22:14, Dean Michael Berris <dberris at google.com> wrote: >> > On Wed, Jun 29, 2016 at 12:06 PM Rafael Espíndola >...

On 28 June 2016 at 22:14, Dean Michael Berris <dberris at google.com> wrote: > On Wed, Jun 29, 2016 at 12:06 PM Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> On 22 June 2016 at 16:36, Dean Michael Berris via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > Peter suggested just writin...

On Wed, Jun 29, 2016 at 12:17 PM Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 28 June 2016 at 22:14, Dean Michael Berris <dberris at google.com> wrote: > > On Wed, Jun 29, 2016 at 12:06 PM Rafael Espíndola > > <rafael.espindola at gmail.com> wrote: > >> > >> On 22 June 2016 at 16:36, Dean Michael Berris via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> &g...

...same binary). So if it's just the two that will be interacting, then sharing flags doesn't seem worth it. But if I'm missing another, then the case for consolidating the flags becomes stronger. Cheers > David > > > On Sun, Jun 26, 2016 at 9:39 PM, Dean Michael Berris <dberris at google.com> > wrote: > >> On Fri, Jun 24, 2016 at 1:44 AM Eric Christopher via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < >>> llvm-dev at lis...

On Sun, Jun 26, 2016 at 10:21 PM, Dean Michael Berris <dberris at google.com> wrote: > > > On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> > wrote: > >> There is some misunderstanding about the intention of this flag. The >> purpose of the flag is not to turn on profile instrumentation (which >...

Thanks for the catch Dead! I'll send out patches to update .arcconfig files to use https. On Thu, Jul 14, 2016 at 3:22 PM Dean Michael Berris <dberris at google.com> wrote: > Thanks Eric, > > If you're like me who started doing this and found some weird errors, you > may have to do the following instead: > > $ arc install-certificate https://reviews.llvm.org/api > > This will update your ~/.arcrc file, where you...

...-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections -O3 -Wl,-z,defs -fuse-ld=gold -Wl,-rpath-link,/usr/local/google/home/dberris/xray/llvm-build/./lib -Wl,-O3 -Wl,--gc-sections -shared -Wl,-soname,liblldCommon.so.6 -o lib/liblldCommon.so.6.0.0svn tools/lld/Common/CMakeFiles/lldCommon.dir/Reproduce.cpp.o tools/lld/Common/CMakeFiles/lldCommon.dir/TargetOptionsCommandFlags.cpp.o tools/lld/Common/CMakeFiles/lldCommon.dir/Thread...

...Call Stack (most recent call first): projects/compiler-rt/lib/xray/tests/CMakeLists.txt:73 (add_xray_lib) Do you think you could take a look? Regards, George > On Apr 10, 2018, at 10:16 PM, Dean Michael Berris via llvm-commits <llvm-commits at lists.llvm.org> wrote: > > Author: dberris > Date: Tue Apr 10 22:16:11 2018 > New Revision: 329776 > > URL: http://llvm.org/viewvc/llvm-project?rev=329776&view=rev > Log: > [XRay][compiler-rt] Fix osx-based builds > > This is a follow-up to D45474. > > Modified: > compiler-rt/trunk/lib/xray/tests/C...

...rofile-instr-generate or -fprofile-generate for it), but to select which instrumentors to use for PGO (IR or FE). I prefer fewer flags too, but sharing flags for completely different purpose does not seem like the right thing to do. David On Sun, Jun 26, 2016 at 9:39 PM, Dean Michael Berris <dberris at google.com> wrote: > On Fri, Jun 24, 2016 at 1:44 AM Eric Christopher via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >&...

...rt_xray_instr_map and __stop_xray_instr_map as weak symbols from the C++ side. I've sent a patch to make creating these COMDAT/Group sections easier when lowering through the MCStreamer interface ( http://reviews.llvm.org/D21743). Cheers On Fri, Jun 24, 2016 at 4:23 AM Dean Michael Berris <dberris at google.com> wrote: > Awesome, thanks Peter! > > Cheers > > On Thu, Jun 23, 2016 at 10:35 AM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> If you give your section a valid C identifier name, i.e. something like >> "xray_instr_map" (no...

On Fri, Jun 24, 2016 at 1:44 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> Sounds fine to me, though I am not a fan of using unstable in the option. >> I think a more meaningful way (that capture the essence of the

...jects/compiler-rt/lib/xray/tests/CMakeLists.txt:73 (add_xray_lib) > > Do you think you could take a look? > > Regards, > George > >> On Apr 10, 2018, at 10:16 PM, Dean Michael Berris via llvm-commits <llvm-commits at lists.llvm.org> wrote: >> >> Author: dberris >> Date: Tue Apr 10 22:16:11 2018 >> New Revision: 329776 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=329776&view=rev >> Log: >> [XRay][compiler-rt] Fix osx-based builds >> >> This is a follow-up to D45474. >> >> Modified: &g...