search for: libtrac

Hi, Is there something wrong with my llvm-gcc compiler?: ------------------------ GNU C version 3.4-llvm 20030924 (experimental) (mingw32) compiled by GNU C version 3.4.1 (mingw special). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:54: error: syntax error before "PRIMES" c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:54: warning: type defaults to `int' in declaration of `PRIMES' c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:56: warning: data definition has no type or storage...

On Fri, 28 Jan 2005, Henrik Bach wrote: > Is there something wrong with my llvm-gcc compiler?: > c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:54: warning: type > defaults to `int' in declaration of `PRIMES' > c:/projects/src/llvm-4/llvm/runtime/libtrace/tracelib.c:56: warning: data > definition has no type or storage class It looks like that file had non-portable code in it. Can you try updating and see...

...BB and print out the values computed in that BB that are live at the end of the BB (so we don't print out temporaries computed and used within the BB), and we also print out values that are loaded or stored from/to memory. You need to link the generated code with /localhome/vadve/llvm/runtime/libtrace/Bytecode/tracelib.bc or /localhome/vadve/llvm/runtime/libtrace/Debug/libtrace.o. Try: % cd test/Programs/SingleSource/Shootout/ % gmake -n TRACE=yes Output/sieve.diff-llc as an example to see how to run the tracing pass and link the generated code. --Vikram http://www.cs.uiuc.edu/~vadve ----...

On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Yes that’s what I’ve been thinking about as well. > > One thing I’ve been giving a lot of thought to is whether to serialize the handling of trace events. I want to balance the “this is a library and you should be able to get it to work for you no matter what your use case is”

no expression parser or knowledge of any specific programming language. Basically I just mean that the parsing of the native DWARF format itself is in scope, but anything beyond that is out of scope. For symbolication we have things like llvm-symbolizer that already just work and are built on top of LLVM's dwarf parsing code. Similarly, LLDB's type system could be built on top of it as

...of the program through opt -tracem, and then generate C code for the result. % opt -tracem bytecode.llvm.bc | llc -f -march=c -o bytecode.tracem.cbe.c 3. Compile the C code with tracing instrumentation using gcc. % gcc -o bytecode.tracem.cbe bytecode.tracem.cbe.c You may have to link it with the libtrace library provided in llvm/runtime/libtrace, in addition to any other libraries that the program needs. > // here, the problem is how can I get external > function pointer. Look at the 'getOrInsertFunction' method of class llvm::Module. > //Instruction *callInst = new...

Hi all, We have been thinking internally about a lightweight llvm-based ptracer. To address one question up front: the primary way in which this differs from LLDB is that it targets a more narrow use case -- there is no scripting support, no clang integration, no dynamic extensibility, no support for running jitted code in the target, and no user interface. We have several use cases internally

On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We have been thinking internally about a lightweight llvm-based > ptracer. To address one question up front: the primary way in which this

...i am going to enter this > > river again. Perhaps, this time all will be fine. > > Sounds great, please let me know how it goes. SuSE 9.1 is running OK. after 30 minute of compilation i get first errors: ********************* make[2]: Leaving directory `/pool/tmp/llvm/runtime/libtrace' make[2]: Entering directory `/pool/tmp/llvm/runtime/libpng' In file included from pngpread.c:12: png.h:329:18: zlib.h: No such file or directory [and alike about zlib.h and others] ********************* my ./configure was: ./configure --enable-optimized --enable-spec2000 --enab...

Hi llvmer, I am trying to learn how to use llvm. My question is described as the following, there has already a testcase code, and I get bytecode by using llvmgcc. What I want to do is to insert a call funcation into each basic block, which is for statistic some information. 1) I implement call function in another c/cpp file and can I insert the external call function to existed bytecode ? if it

...ries/libutempter/Depend ? llvm/runtime/GCCLibraries/libutil/BytecodeObj ? llvm/runtime/GCCLibraries/libutil/Depend ? llvm/runtime/libdummy/BytecodeObj ? llvm/runtime/libdummy/Depend ? llvm/runtime/libprofile/BytecodeObj ? llvm/runtime/libprofile/Debug ? llvm/runtime/libprofile/Depend ? llvm/runtime/libtrace/BytecodeObj ? llvm/runtime/libtrace/Debug ? llvm/runtime/libtrace/Depend ? llvm/tools/Debug ? llvm/tools/analyze/Debug ? llvm/tools/analyze/Depend ? llvm/tools/bugpoint/Debug ? llvm/tools/bugpoint/Depend ? llvm/tools/extract/Debug ? llvm/tools/extract/Depend ? llvm/tools/gccas/Debug ? llvm/tools/g...

...acem, and then > generate C code for the result. > % opt -tracem bytecode.llvm.bc | llc -f -march=c -o bytecode.tracem.cbe.c > > 3. Compile the C code with tracing instrumentation using gcc. > % gcc -o bytecode.tracem.cbe bytecode.tracem.cbe.c > You may have to link it with the libtrace library provided in > llvm/runtime/libtrace, in addition to any other libraries that > the program needs. > > > // here, the problem is how can I get external > > function pointer. > > Look at the 'getOrInsertFunction' method of class llvm::Module. >...

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

...dri/common/utils.o ../../../../src/mesa/drivers/dri/common/dri_util.o ../../../../src/mesa/drivers/dri/common/xmlconfig.o ../../../../src/gallium/state_trackers/dri/drm/libdridrm.a ../../../../src/gallium/winsys/nouveau/drm/libnouveaudrm.a ../../../../src/gallium/drivers/trace/libtrace.a ../../../../src/gallium/drivers/rbug/librbug.a ../../../../src/gallium/drivers/nv30/libnv30.a ../../../../src/gallium/drivers/nv50/libnv50.a ../../../../src/gallium/drivers/nvc0/libnvc0.a ../../../../src/gallium/drivers/nouveau/libnouveau.a \ -Wl,--start-...

You'd probably need to pull the Unwinder in if you want backtraces, but that part shouldn't be that hard to disentangle. I don't think you'd need much else? Basing your work on NativeProcess rather than lldb proper would also cut the number of observer processes in half and avoid the context switches between the server and the debugger. That seems more appropriate for a

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

...ries/libutempter/Depend ? llvm/runtime/GCCLibraries/libutil/BytecodeObj ? llvm/runtime/GCCLibraries/libutil/Depend ? llvm/runtime/libdummy/BytecodeObj ? llvm/runtime/libdummy/Depend ? llvm/runtime/libprofile/BytecodeObj ? llvm/runtime/libprofile/Debug ? llvm/runtime/libprofile/Depend ? llvm/runtime/libtrace/BytecodeObj ? llvm/runtime/libtrace/Debug ? llvm/runtime/libtrace/Depend ? llvm/tools/Debug ? llvm/tools/analyze/Debug ? llvm/tools/analyze/Depend ? llvm/tools/bugpoint/Debug ? llvm/tools/bugpoint/Depend ? llvm/tools/extract/Debug ? llvm/tools/extract/Depend ? llvm/tools/gccas/Debug ? llvm/tools/g...

...> > river again. Perhaps, this time all will be fine. > > > > Sounds great, please let me know how it goes. > > SuSE 9.1 is running OK. > after 30 minute of compilation i get first errors: > ********************* > make[2]: Leaving directory `/pool/tmp/llvm/runtime/libtrace' > make[2]: Entering directory `/pool/tmp/llvm/runtime/libpng' > In file included from pngpread.c:12: > png.h:329:18: zlib.h: No such file or directory > [and alike about zlib.h and others] > ********************* Please apply this patch to your tree: Index: Makefile =====...

...../src/mesa/drivers/dri/common/utils.o ../../../../src/mesa/drivers/dri/common/dri_util.o ../../../../src/mesa/drivers/dri/common/xmlconfig.o ../../../../src/gallium/state_trackers/dri/drm/libdridrm.a ../../../../src/gallium/winsys/nouveau/drm/libnouveaudrm.a ../../../../src/gallium/drivers/trace/libtrace.a ../../../../src/gallium/drivers/rbug/librbug.a ../../../../src/gallium/drivers/nvfx/libnvfx.a ../../../../src/gallium/drivers/nv50/libnv50.a ../../../../src/gallium/drivers/nvc0/libnvc0.a ../../../../src/gallium/drivers/nouveau/libnouveau.a \ -Wl,--start-group ../../../../src/mes...