similar to: [LLVMdev] Cross-compiling Compiler-RT builtins

In the effort to flesh out the CMake build system a problematic issue has come up, and I’d like some feedback on how to best handle it. For reference this issue has been reported by a few users, one proposed patches that don’t really address the underlying problem here: http://reviews.llvm.org/D13131 The problem comes when bootstrapping a cross-compiler toolchain. In order to have a

Hi, There are several places in compiler-rt which refer to __aeabi_idiv0. For example, in lib/builtins/arm/udivsi3.S: #ifdef __ARM_EABI__ b __aeabi_idiv0 #else JMP(lr) #endif At the same time there is no definition of it. It looks as if it was done intentionally so that third-party could provide custom handler for division by zero. IMHO It's not very consistent and looks odd as

Hi, I'm trying to link my objs with compiler-rt built runtime lib for arm. According to the compiler-rt doc, it should be able to replace libgcc. However, if I replace "-lgcc" with "compiler-rt.a" for a static linking, gcc linker complains about undefined functions. Using "nm -g", I compared the functions in libgcc and compiler-rt.full-arm.a and found there are

Hello all, I’m unsure of how the tests located in compiler-rt/test/builtins/Unit are run. They’re not attached to the cmake check-all target, as mentioned in compiler-rt/test/CMakeLists.txt:10, and they have no lit test suite associated with them. There is a shell script called “test” in test/builtins/Unit, but it hasn’t been touched since 2010, and make reference to no longer existing

Hello It seems you misses several points here... > So, you mean I should compile libc with clang and link with compiler-rt too? > But how can we expect a user of compiler-rt have a libc compiled in this > way? It's a part of gcc's src code... No it is not > If compiler-rt is a complete lib, it should also cover these functions, right? Yes and no. Yes - it should cover all

Hello, I recognized that compiler-rt's the implementation of __aeabi_memcpy simply branches to memcpy. The implementation of memcpy is not provided. So an externally provided memcpy () has to be used. (also applies to memmove, memset, memclr) On ARM I have seen implementations of memcpy () using floating-point registers (if compiled with NEON support). The is perfectly legal, as memcpy ()

> On Nov 2, 2015, at 12:01 PM, Steve King <steve at metrokings.com> wrote: > > Hi Chris - Many thanks for airing all this. I'm now hopeful for an > end to my own hacks and false starts trying to fix these same > problems. My response is coming from the perspective of an > out-of-tree target without binutils or libgcc support. > > On Mon, Nov 2, 2015 at 9:10

On 31 Jan 2014, at 08:12, Chandler Carruth <chandlerc at google.com> wrote: > - There is the core runtime library. Historically this was called 'compiler-rt' informally, but perhaps better called 'libclang_rt', which provides the core necessary runtime library facilities to compile C or C++ applications. It's analogous to libgcc but without some of the unwinding code

Would the __probestack functions be a suitable addition to compiler-rt? Does it already have __chkstk or is that provided by something else on Windows? I noticed that libgcc implemented them in cygwin.S. On Mon, Aug 4, 2014 at 9:08 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 08/01/2014 05:38 PM, John Kåre Alsaker wrote: > > On Fri, Aug 1, 2014 at 11:12 PM,

On 1 February 2014 00:44, Nick Kledzik <kledzik at apple.com> wrote: > * One of the interesting things about compiler-rt is the static library to > dynamic library migration (e.g. libgcc.a vs libgcc_s.so, or on Darwin > libclang_*.a vs libSystem.dylib). If the shared library ships > independently from the compiler, then the compiler may need a .a file that > can ship with it

Hi all, compiler-rt is now not only a libgcc replacement for different platforms, there are sanitizer and profile runtimes as well. I plan to move the files as follows during this week: 1. libraries: a) all libgcc replacement stuff moves from "/lib" to "/lib/core" (the name sucks, please suggest alternatives). Same for platform-specific code:

On Fri, Sep 5, 2014 at 11:32 AM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > Sergey, > > Not that it'll save you much hassle, but here's an implementation of > __aeabi_idiv0 and __aeabi_ldiv0 that I've been sitting on for a while. > > I vaguely remember compnerd suggesting that I don't commit them to > compiler_rt, but I don't remember

Hi, Short version: Is it possible to enable *all* builtins architectures? How? Longer explanation: I don't quite understand how compiler-rt targets are decided to be built while invoking cmake from the LLVM tree. I tend to believe that builtins and sanitizers (the two big parts in compiler-rt) are quite different monsters, but however they share the same build decisions and (if I'm not

I updated http://reviews.llvm.org/D4717 and also wrote an __probestack implementation: https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe Which instruction would be the preferable one to probe with? I used OR since that's what GCC/libgcc does, but I don't see why that would be better than a write. On Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at

On Nov 15, 2012, at 9:33 PM, liangh at codeaurora.org wrote: > I'm trying to link my objs with compiler-rt built runtime lib for arm. > According to the compiler-rt doc, it should be able to replace libgcc. > However, if I replace "-lgcc" with "compiler-rt.a" for a static linking, > gcc linker complains about undefined functions. Using "nm -g", I

Since David Majnemer doesn't seem overly eager to merge my patches, let's see if we can't figure things out here. I noticed a string function attribute appeared in LangRef.rst, would that be the correct place to document this? For reference: http://reviews.llvm.org/D9653 http://reviews.llvm.org/D9654 http://reviews.llvm.org/D9858 On Wed, Aug 6, 2014 at 5:34 PM, John Kåre Alsaker

> Does clang provide other replacing libs for them which don't depend on > those missing functions on libgcc? Or there are some other ways to link? > Currently I have to link with both compiler-rt and libgcc with > "--allow-multiple-definition" so that libgcc can cover the missing > functions in compiler-rt. But this is not a clean solution, and I have > trouble

Hi guys, Thanks for all the info. Then, if, besides compiler-rt, I also need some other libs, such as libm, how do I link? Here is an example of missing functions in compiler-rt when linking: "-lstdc++ -lm --start-group -lcompiler-rt-armv7 -lgcc_eh -lc --end-group" vs. "-lstdc++ -lm --start-group -lgcc -lgcc_eh -lc --end-group" ...

> On Nov 2, 2015, at 11:41 AM, Vasileios Kalintiris <Vasileios.Kalintiris at imgtec.com> wrote: > >> The problem comes when bootstrapping a cross-compiler toolchain. In order to >> have a cross-compiling toolchain that can build a “hello world” application you >> need four basic components: >> >> (1) clang >> (2) ld >> (3) libclang_rt

Yeah, the function attributes section of LangRef is a reasonable place to put stuff like this: http://llvm.org/docs/LangRef.html#function-attributes I think we should add this. I also know that LLILAC needs something like this as well. I propose the following: - Add a string attribute called "stack-probe-symbol"="foo". - The presence of this attribute indicates that stack