similar to: What is compiler-rt for?

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

So, I remember we discussed this earlier this year, but I can't find the thread. The idea is to move libunwind into compiler-rt for the simple reasons below: 1. Unwinding is not exclusive to C++, nor exception handling. 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt (maybe eh isn't needed, but it was there for libgcc). 3. Testing the libunwind with libc++ on ARM is

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:

I would still urge folks to consider keeping distinct functionality in separate places. Agreed, it makes more sense for the [language agnostic] unwinder to be in compiler-rt than libcxxabi -- but IMO it makes even more sense for it to be distinct. The bundling of the unwinder with libgcc_s gave us (i.e. 3rd party folks, outside the vendor's organisation) nothing but headaches. Much

Hi David, On Wed, Feb 12, 2014 at 5:22 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 12 Feb 2014, at 13:21, Alexey Samsonov <samsonov at google.com> wrote: > > > On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > >> Are you going to move the unwind library there as part of the >

On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > Are you going to move the unwind library there as part of the > reorganisation? > No. > > David > > On 11 Feb 2014, at 09:59, Alexey Samsonov <samsonov at google.com> wrote: > > > Hi all, > > > > compiler-rt is now not only a libgcc replacement for

Hello, we're looking at packaging up our current NetDirector bug fix release and we want it available as .rpm at this moment, the maintainers don't have a test environment for Centos does anyone know whether the latest versions of and Centos can satisfy Tomcat 5 and Java 1.4 JDK as dependencies? thanks in advance! -- Greg Wallace Project: www.netdirector.org Blog:

On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing > of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that > it's not possible to test libunwind on arm-linux when using compiler_rt? Yeah, it's hard and clumsy, not impossible. Basically,

I am attempting to port an operating system project to use Clang/LLVM instead of GCC, but I'm having issues with Compiler-RT. Right now, the OS is being cross-compiled on an x86_64 host targeting ARMv7a. I built the LLVM toolchain according to the instructions, though I limited the supported targets to arm, x86, and x86_64 to reduce compilation time. I'm finding that compilation proceeds

Hi, In sanitizer code we have two notions of stack unwinders: fast and slow. [1] In the context of sanitizers, stack unwinding is most often for printing error reports that include a stack trace. I am currently trying to fix an issue that is related to some platforms (Darwin) only supporting the fast unwinder, but calling code not being aware of that possibility. My mental model was that

In lib/gcc_personality_v0.c, I believe the type of the exception_cleanup member of the struct _Unwind_Exception is incorrect. It has a return type of _Unwind_Reason_Code versus a return type of void as specified in http://refspecs.freestandards.org/abi-eh-1.21.html, and as can be seen in unwind.h on Linux, and OS X 10.6.x (the latter's unwind.h is under the Developer directory tree). The

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

I recently debugged an issue where I wasn't getting stack traces from ASAN on 32-bit ARM (on Android) when using a libclang_rt.asan-arm-android.so I'd built myself. I finally ended up tracing it to a build issue; the CMake build check for -funwind-tables was failing (because of some missing link libraries), so compiler-rt wasn't being built with that flag, which in turn led to all

Hello, In continuation of several threads from the last week, I'd like to ask: is there a stated plan of what is going to happen with compiler-rt in the near future? In particular, I'm interested if any of the following is planned to happen: - Separation from clang I've seen a suggestion to rename compiler-rt to "libclang_rt", but its' applicability is much broader than

Tried a small test just now to see how exception handling on Windows is getting on, and it seems to work except for one thing. clang-cl /EHsc (the Microsoft compiler option to enable exceptions) doesn't do anything; they remain disabled. However, -Xclang -fcxx-exceptions succeeds. Is this a bug in the handling of compatibility options or am I missing something? -------------- next part

On 30 January 2014 21:50, Reid Kleckner <rnk at google.com> wrote: > > I don't see any compelling reason to split the sanitizers out today. > Clear, next. I think the sanitizer guys would probably take a patch to CMakeLists.txt to > disable the sanitizer RTLs. > Right. I'll first make it build and test, than I'll disable via a flag, since other people can work

On Wed, Oct 22, 2014 at 11:24 AM, Jonathan Roelofs < jonathan at codesourcery.com> wrote: > I remember there being a ARM EHABI reason why this won't work, but I don't > remember the specifics. IIRC, had something to do with how c++ rtti is > required > to be handled by the catch handlers, and would mean layering problems if we > moved it. Antoine, do you remember the

Hi Duncan, Hi Bjarke, Duncan Sands wrote: > Take a look at libunwind (http://www.hpl.hp.com/research/linux/libunwind/). > Another possibility, very close you yours and currently used by the vmkit > project, is to modify all functions so they return two values, the usual > return value and an additional boolean value indicating whether an exception > was thrown during the call or

> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 15:23, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> Hi Peter, >> >> Thanks for your response. >> >> On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote:

> On 18 Nov 2019, at 22:11, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 17:06, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> >> >> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: >> >> On Mon, 18 Nov 2019 at 15:23, Sergej