search for: dtors

Hello, While instrumenting LLVM IR in ThreadSanitizer (race detector), I need to distinguish between a store to vtable pointer (vptr) and any other regular store. This special treatment should be limited to class DTORs, so I should also know when a function is a DTOR. Rationale: need to distinguish benign and harmful races on vptr ( http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr ). Currently, I can figure out when a function is a DTOR and when a store touches vptr by analyzing ma...

Hello all! I extended the LDC2 with a pragma to register a funcion in the llvm.global_ctors or llvm.global_dtors list. On Linux, references to these functions are placed in .ctors and .dtors sections and everything runs fine. On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, which is automatically called by the MS C Runtime. However, functions from llvm.global_dtors are placed...

On Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote: > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need to distinguish between a store to vtable pointer (vptr) and any other regular store. > This special treatment should be limited to class DTORs, so I should also know when a function is a DTOR. > Rationale: need to distinguish benign and harmful races on vptr (http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr). > > Currently, I can figure out when a function is a DTOR and when a store touches vptr...

...oes away, the module's dtor will be called first, deleting the module, then the MP's dtor will be called, which will try to delete the same module again. 2a) So either we can prevent the actual destruction of modules that are attached to MPs, or 2b) Do not do anything in the dtors of MPs (while letting the dtor of modules do the work) Both options have the disadvantage of assuming the C/C++ implementation (like MP::dtor deletes only the module and nothing else). > The routine LLVMModuleRef > LLVMGetGlobalParent(LLVMValueRef Global); poses a related problem; in th...

Hello > On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, > which is automatically called by the MS C Runtime. Only if you link with MS runtime. Mingw follows standard .ctors / .dtors scheme. > My expectation was that the dtors placed in .CRT$XTU which are the C > terminator functions. Maybe there is a way to customize this? Yes. Target (or,rather subtarget) specifies this. Looks like it was somehow missed for dtors. > - How can I control section attributes and alingm...

...2 PM, Kostya Serebryany <kcc at google.com> wrote: > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need > to distinguish between a store to vtable pointer (vptr) and any other > regular store. > This special treatment should be limited to class DTORs, so I should also > know when a function is a DTOR. > Rationale: need to distinguish benign and harmful races on vptr > (http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr). > > Currently, I can figure out when a function is a DTOR and when a store > t...

...r > will be called first, deleting the module, then the MP's dtor will > be called, which will try to delete the same module again. > > 2a) So either we can prevent the actual destruction of modules that > are attached to MPs, or > > 2b) Do not do anything in the dtors of MPs (while letting the dtor of > modules do the work) The ModuleProvider itself also needs to be destroyed or you have a memory leak. > Both options have the disadvantage of assuming the C/C++ > implementation (like MP::dtor deletes only the module and nothing > else). &gt...

...Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote: > > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need > to distinguish between a store to vtable pointer (vptr) and any other > regular store. > This special treatment should be limited to class DTORs, so I should also > know when a function is a DTOR. > Rationale: need to distinguish benign and harmful races on vptr ( > http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr > ). > > Currently, I can figure out when a function is a DTOR and when a store...

From: Matt Fleming <matt.fleming at intel.com> GCC 4.7 now places pointers to functions with the 'constructor' and 'destructor' function attributes in .init_array and .fini_array sections, respectively, whereas previously they were in the .ctors and .dtors sections. This change breaks the ctors/dtors code as it only expects function to be in the .ctors and .dtors sections, meaning the ctors and dtors functions are never executed. While a COM32_INIT() macro exists that places functions in the .init_array section, no function makes use of it, so there...

I am nuilding that now. CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_SHARED_LIBS=ON \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \ -DLLVM_HOST_TRIPLE=x86_64-pc-linux-gnu \ -DLLVM_TARGETS_TO_BUILD="AMDGPU;MSP430;WebAssembly;X86" \

...ata.*) __rodata_end = .; } - . = ALIGN(4); - - __ctors_vma = .; - __ctors_lma = __ctors_vma + __text_lma - __text_vma; - .ctors : AT(__ctors_lma) { + .ctors : AT(ADDR(.ctors) + __vma_to_lma) { __ctors_start = .; KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) __ctors_end = .; } - __dtors_vma = .; - __dtors_lma = __dtors_vma + __text_lma - __text_vma; - .dtors : AT(__dtors_lma) { + .dtors : AT(ADDR(.dtors) + __vma_to_lma) { __dtors_start = .; KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) __dtors_end = .; } - . = ALIGN(4); - - __dynsym_vma = .; - __dynsym_lma = __dynsym_v...

...eting the module, then the MP's dtor will > > be called, which will try to delete the same module again. > > > > 2a) So either we can prevent the actual destruction of modules that > > are attached to MPs, or > > > > 2b) Do not do anything in the dtors of MPs (while letting the dtor of > > modules do the work) > > The ModuleProvider itself also needs to be destroyed or you have a > memory leak. > > > > Both options have the disadvantage of assuming the C/C++ > > implementation (like MP::dtor deletes only t...

Hi, I noticed that there are some diagnostics discrepancies between clang and gcc related to `__attribute__((constructor(n)))` and `__attribute__((destructor(n)))`. *[clang]* It seems priorities >65535 and <0 on ctor/dtor functions are ignored and are set back to default 65535 in clang and Clang only gives an error when > 32-bit unsigned value specified. *[g++]* g++ gives an error for

Hi, Using master at b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8, I cannot build LLVM. I configured with: CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=OFF \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \

On May 10, 2008, at 05:44, Mahadevan R wrote: > I'd like to announce the availability of Python bindings for LLVM. > > It is built over llvm-c, and currently exposes enough APIs to build > an in-memory IR (and dump it!). It needs LLVM 2.3 latest and Python > 2.5 (2.4 should be sufficient, but I haven't tested). Tested only on > Linux/i386. > > Would love to

Do you really need to build the C library for MLIR? If so, it looks like it's just a missing dependency - MPFR library. Or if you do have that library available, it's missing expected features. On Thu, Apr 23, 2020 at 12:29 PM Luke A. Guest via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Here's the error: > > [1921/7570] /usr/lib/llvm/10/bin/clang++

From: Sylvain Gault <sylvain.gault at gmail.com> TL;DR: The section aligment in linker scripts messed-up the memory mapping needed for the compression / decompression to work. The bug with gcc 5 is not trivial, I'll do my best to explain it here. Basically, there are two memory mappings of the code. One in "virtual memory", and one in "load memory". The one in

One could argue that mclinker is doing something good or not by how it's using this class but I don't see the need for parser<bool> to be final. That is a subjective opinion that mclinker needs to be changed. I think that "final" was added to some of these command line classes to avoid some kind of clang warning. That seems wrong to me that the tools are dictating

...Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote: > > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need > to distinguish between a store to vtable pointer (vptr) and any other > regular store. > This special treatment should be limited to class DTORs, so I should also > know when a function is a DTOR. > Rationale: need to distinguish benign and harmful races on vptr > (http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr). > > Currently, I can figure out when a function is a DTOR and when a store > t...

For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It seems like VP4.0 is basically working here... only mpeg2/vc1 work, but I'm pretty sure that's just a user-side issue. My guess is