similar to: [LLVMdev] use of undeclared identifier '__NR_*' error while building clang

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

Hi, Chatsiri! > ---------- Forwarded message ---------- > From: Chatsiri Ratana <insiderboy at gmail.com> > Date: Wed, Jun 6, 2012 at 2:15 PM > Subject: [LLVMdev] Compile-rt throw error undeclared identifier 'O_CLOEXEC' > To: llvmdev at cs.uiuc.edu > > > Hello All, > > I build LLVM source code version 3.2 from SVN repository. After I > build

On Wed, Jun 6, 2012 at 5:33 PM, Alexey Samsonov <samsonov at google.com> wrote: > Hi, Chatsiri! > > >> ---------- Forwarded message ---------- >> From: Chatsiri Ratana <insiderboy at gmail.com> >> Date: Wed, Jun 6, 2012 at 2:15 PM >> Subject: [LLVMdev] Compile-rt throw error undeclared identifier >> 'O_CLOEXEC' >> To: llvmdev at

Hello, I'm quite new to LLVM, but I'm interested in memory sanitizer. The petty thing is, that 32bit addressing on Linux is not supported. Thus I tried to take the latest version of the software and to modify it, using Ubuntu 16.04 as operating system. Given the example example.c: #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { int *a = (int

Hello Gergö, Joerg and people on our list With your kind answer, I tried to build a hello world program for ARM(arm-none-linux-gnueabi) on my x86-64 PC. Thank you we verified the generated bitcode. The only thing remained is linking. Let me brief what I did so far. 1. Built Clang/llvm in a way explained in http://clang.llvm.org/get_started.html on Ubuntu 11.10 x86-64 PC 2. Downloaded gcc-4.0

Hello > ./clang -v -emit-llvm -ccc-host-triple arm-none-linux-gnueabi > -I/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/include > -L/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin hello.c You forgot about sysroot here. > /home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin/ld: > unrecognised emulation mode: armelf_linux_eabi >

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

On Sat, Jun 16, 2012 at 08:20:23PM +0900, Journeyer J. Joh wrote: > If the cross compiling is supported, is there any documentation on how to > do it? The short version is: assuming you have a cross-binutils installation using e.g. x86_64--netbsd-as and x86_64--netbsd-ld, you add a symlink called x86_64--netbsd-clang to clang and just call that with an appropiate --sysroot to make it find

Hello list, I wonder if llvm/Clang can compile C or C++ for ARM from on x86. http://comments.gmane.org/gmane.comp.compilers.clang.devel/8896 The talk above answered 'NO' to my question, which means Clang is not yet able to cross compile for ARM on X86. Is the answer still correct for my question? I saw somewhere that Clang supports ARM on Darwin only. Then is the cross compiling

Hello, Thank you for your kind attention to my issue and your help. I changed the tool chain and tried again. And there is a little progress but still have some problem. Using --sysroot doesn't make clang use linker(ld) in the cross tool. Most important question is how I can make clang use cross tool linker. Let me show you my experiment and questions below. There are two questions. [Run]

Hi, It seems that r327904 / 5c4cd77db3a08587c6ac82a8e2c92cd4be0bc200 broke master on FreeBSD: A direct revert fixes the issue. I'd also be happy with an ifdef though it seems unnecessary. $uname -rms FreeBSD 12.0-CURRENT amd64 $ninja ... /srv/src/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:504:25: error: no member named 'environ' in the global namespace;

Hi, I see that ENABLE_WERROR is being set to off (the default value) in the config.log in the llvm build. However on grepping for WERROR in the compiler-rt folder I get the following output: pranav at pranav:~/smack-project/llvm-3.4/src/projects/compiler-rt$ grep -Rin WERROR * lib/asan/tests/CMakeLists.txt:38: -Werror lib/asan/asan_malloc_mac.cc:253:// This function is currently unused, and we

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

On PowerPC we have a failing address sanitizer test when linking with LLD. The issue is that the symbol '__libc_stack_end' is resolved to an undefined weak symbol when linking with LLD but not when linking (with the exact same command/input) with other linkers. Tracing the symbol I see it is resolved to a definition in the dynamic linker as expected:

Dear Alexey, Yes I am sure that the llvm, clang and compiler-rt are synced to the same version. I downloaded them all from git http://llvm.org/docs/GettingStarted.html#git-mirror I think I need compiler-rt for my project but I'll verify it again to see if I can proceed without it. You are correct that compiler-rt is compiled with the just built clang. The complete command that gives an error

On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The sanitizer common and asan that mention 'thread' are failing for me > this morning. How are your bots looking? Last good commit here was > 512c616cacf70ca029a2bf719a482b902f3687cd. > Hm, our bots seem to be green. Could you refer to guilty svn revision? > > > You could try

Hi all, I experienced some test failures under Linux, probably caused by r232936: In the test SanitizerCommon-Unit :: Sanitizer-i386-Test/MemoryMappingLayout.CodeRange the temporary test file was opened write-only, but was read from, what subsequently failed: Note: Google Test filter = MemoryMappingLayout.CodeRange [==========] Running 1 test from 1 test case. [----------] Global test

yes I think that is correct. I wrote a simple program to print if sizeof(uintptr_t) != sizeof(unsigned char *) and when I compile with gcc -m64 and execute it on a 64-bit host (that is different from the 32-bit laptop on which I originally compiled the program), it says the sizes are not equal. Thanks Pranav On Thu, Aug 1, 2013 at 9:29 AM, Alexey Samsonov <samsonov at google.com> wrote:

Hi Kostya, >On Wed, Nov 12, 2014 at 2:50 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch >> wrote: > >> Dear LLVM developers, >> >> We've applied the feedback we received on Phabricator on the SafeStack >> patches, >> > >Did you investigate the possibility of moving the transformation from >codegen to the LLVM level, i.e. the same level

Hi Sanitizer Runtime Developers, We recently ran into a problem building clang because some of the definitions in sanitizer_common conflicted with system definitions and later another system header was trying to use the system definition: .../usr/include/libkern/OSAtomicDeprecated.h:756:17: error: reference to 'memory_order_relaxed' is ambiguous __theAmount, memory_order_relaxed) +