Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc"
2013 Mar 14
2
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
Thanks for your reply.
May I know which is the recommended library that should be linked against?
I am currently linking libprofile_rt.a.
And I have noticed the differences that, if we do
`nm libprofile_rt.a | grep llvm`
with my old copy of the llvm/clang installation, I can see
00000000000005e0 T _llvm_gcda_emit_arcs
0000000000000b48 S _llvm_gcda_emit_arcs.eh
0000000000000430 T
2013 Mar 15
2
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
On Fri, Mar 15, 2013 at 1:36 AM, Qun Fa <testforqunfa at gmail.com> wrote:
> Hi All,
>
> I think Nick's suggestion is correct, my code was linked against
> libprofile_rt.a, which had gcda profiling code before, but was removed
> https://github.com/llvm-mirror/llvm/commit/218042a02305a3cc38d968a97ff9ecf4b4abe6ff
>
> So, I couldn't find the correct symbols from
2013 Mar 14
0
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
Qun Fa wrote:
> Hi,
> I am trying to test my project and get the code coverage with a version
> of clang compiler that was built from the latest llvm/clang codebase.
>
> It worked for a while. But today, after I updated my local checkout, and
> re-build llvm, clang and compiler-rt, when I test my project again, I
> got the errors with undefined reference to
2013 Mar 19
2
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
Hi!
On Fri, Mar 15, 2013 at 10:51 PM, Qun Fa <testforqunfa at gmail.com> wrote:
> Thank you Alexey.
>
> I have tried to use Makefile. This will generate the correct symbols that
> I need.
>
> Any idea on the schedule of adding CMake support to compiler-rt?
>
Starting from r177382 CMake on Linux should build the same profile
compiler-rt library
as Makefiles.
>
2013 Mar 14
0
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
Hi All,
I think Nick's suggestion is correct, my code was linked against
libprofile_rt.a, which had gcda profiling code before, but was removed
https://github.com/llvm-mirror/llvm/commit/218042a02305a3cc38d968a97ff9ecf4b4abe6ff
So, I couldn't find the correct symbols from libprofile_rt.a any more.
Now my assumption is I need to use the correct library that is provided by
compiler-rt.
2013 Mar 15
0
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
Thank you Alexey.
I have tried to use Makefile. This will generate the correct symbols that I
need.
Any idea on the schedule of adding CMake support to compiler-rt?
Sincerely,
Qun
On Fri, Mar 15, 2013 at 1:51 AM, Alexey Samsonov <samsonov at google.com>wrote:
>
> On Fri, Mar 15, 2013 at 1:36 AM, Qun Fa <testforqunfa at gmail.com> wrote:
>
>> Hi All,
>>
2013 Mar 25
0
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
Thank you Alexey. I will try this out this week. Any idea on supporting
this for Mac?
My raw idea is to add this to compiler-rt/lib/profile/CMakeLists.txt
if(APPLE)
foreach(arch ${PROFILE_SUPPORTED_ARCH})
add_compiler_rt_static_runtime(clang_rt.profile-${arch} ${arch}
SOURCES ${PROFILE_SOURCES}
CFLAGS --sysroot=${COMPILER_RT_DARWIN_SDK_SYSROOT})
endforeach()
endif()
Do you
2013 Mar 25
1
[LLVMdev] undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs', etc
On Mon, Mar 25, 2013 at 5:04 PM, Qun Fa <testforqunfa at gmail.com> wrote:
> Thank you Alexey. I will try this out this week. Any idea on supporting
> this for Mac?
>
> My raw idea is to add this to compiler-rt/lib/profile/CMakeLists.txt
>
> if(APPLE)
> foreach(arch ${PROFILE_SUPPORTED_ARCH})
> add_compiler_rt_static_runtime(clang_rt.profile-${arch} ${arch}
2016 Apr 06
2
Writing a test for gcov style coverage crashing after dlclose
Hi Everyone,
I have uploaded a patch that allows one to successfully gather gcov/gcda
coverage information on programs which unload shared libraries. It¹s a
simple fix, just adding a few COMPILER_RT_VISIBILITY (i.e.
__attribute__((visibility("hidden")))) in GCDAProfiling.c.
Now, I¹d like to include a test program to demonstrate the fix. AFAICT,
there seems to be a single test for
2013 Mar 15
0
[LLVMdev] Problems about developing LLVM pass on windows visual studio
I just want to know ,how can I developing a LLVM Pass on Windows' visual
studio?
I can develop a Pass on linux,but I can't do it on windows.
2013/3/15 <llvmdev-request at cs.uiuc.edu>
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
2013 Aug 30
2
[LLVMdev] Fix crash in llvm_gcda_emit_arcs()
Hi,
I've been seeing a crash in llvm_gcda_emit_arcs() on x86_64. The crash
occurs executing a movdqa instruction with an unaligned src address. The
attached patch to the compiler-rt project fixes the problem by using
memcpy() to read data from the write_buffer[] in GCDAProfiling.c.
This is my first patch submission to llvm so please let me know if I've
missed any steps. I'm not on
2013 Sep 05
2
[LLVMdev] Fix crash in llvm_gcda_emit_arcs()
Hi Nick,
Thanks for looking over my patch. I'd be happy to add the compare against
cur_buffer_size. I'll try to write up such a change today and then send a
new patch to the list.
Joseph Kain
On Thu, Sep 5, 2013 at 1:37 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Bill, could you take a look at this? I don't have a checkout of
> compiler-rt that builds.
>
>
2013 Sep 05
0
[LLVMdev] Fix crash in llvm_gcda_emit_arcs()
Bill, could you take a look at this? I don't have a checkout of
compiler-rt that builds.
It seems obviously-correct to me, but I wish it did a compare against
cur_buffer_size to make sure it's in range.
Nick
Joseph Kain wrote:
> Hi,
>
> I've been seeing a crash in llvm_gcda_emit_arcs() on x86_64. The crash
> occurs executing a movdqa instruction with an unaligned src
2013 Sep 05
0
[LLVMdev] Fix crash in llvm_gcda_emit_arcs()
Hi Nick and Bill,
Attached is a new version of the patch that checks against cur_buffer_size.
This works with the cases I've been using but again I haven't run the
official tests on this change.
Thanks,
Joseph Kain
On Thu, Sep 5, 2013 at 9:46 AM, Joseph Kain <joekain at gmail.com> wrote:
> Hi Nick,
>
> Thanks for looking over my patch. I'd be happy to add the
2005 Jan 05
1
(no subject)
Googling for `rw1061.exe' turned up:
http://www.cipic.ucdavis.edu/~dmrocke/Class/EAD289D/R/rw1061.exe
Andy
> From: Qun Shi
>
> Hi Andy,
>
> Thanks a lot for your promptly response. I searched the whole
> web site, I
> found the source code for version 1.6.X. Since I'm not a
> computer person,
> I don't how to compile it, but what I want is binary file
2005 Jan 05
1
(no subject)
Sources for versions of R as far back as 0.65, I believe, are available on
CRAN. You can try to compile from source.
Andy
> From: Qun Shi
>
> Hi,
>
> I'm trying to use the version of dchip combined with R to
> analyze my data.
> I need R version 1.6 which fits for dchip as dchip manual said. So I
> would appreciate a lot if someone could tell me where I could
2014 Jun 17
5
[LLVMdev] does ENABLE_COVERAGE work?
Hi,
I'd like to see what parts of LLVM/Clang are being executed.
I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on
64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head
using any of Clang 3.4, Clang head, or a recent GCC.
The first error that I get when building with GCC is this:
2013 Jan 03
4
[LLVMdev] Fatal error in build, include <utility> not found
I'm trying to customize llvm by adding a header file of my own and tweaking
things accordingly.
While building, things go well until a certain point where it stops seeing
the includes of my file.
I'm working on Ubuntu 12.04 with llvm-3.1 on a custom target (mips-like),
gcc-4.6 and clang-3.2 (i've tried 3.1 too).
>From what i've understood, when it builds the first binaries of
2013 Oct 03
2
[LLVMdev] question about -coverage
Hello,
I have few questions about coverage.
Is there any user-facing documentation for clang's "-coverage" flag?
The coverage instrumentation seems to happen before asan, and so if asan is
also enabled
asan will instrument accesses to @__llvm_gcov_ctr.
This is undesirable and so we'd like to skip these accesses.
Looks like GEP around @__llvm_gcov_ctr have special metadata
2013 Aug 22
2
[LLVMdev] [RFC PATCH] X32 ABI support for Clang/compiler-rt (compiler-rt patch)
X32 support patch for compiler-rt. Applies against current trunk.
--- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21
06:27:38.000000000 +0000
+++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21
11:16:55.891621025 +0000
@@ -41,7 +41,18 @@
SupportedArches += x86_64
endif
else
- SupportedArches := x86_64
+ # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit