similar to: [LLVMdev] Producing a stack dump via libunwind?

Hi Talin, > I'm using the LLVM exception handling intrinsics, along with a custom > personality function, to do exception handling and it is working well. > Now, I would like to add the ability to produce a human-readable stack > backtrace for exceptions which are not caught (or rather, which are > caught by some top-level function which prints the exception's stack

Hello. I was trying to compile https://github.com/llvm/llvm-project/tree/master/libunwind using: - MSVC - Clang I wasn't able to configure this project for using MSVC (directly or via clang-cl): >cmake -G Ninja -DLLVM_PATH="C:/Users/clang/llvm-project-10.0.1/llvm" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="C:\Users\clang\libunwind_llvm" ../libunwind --

I'd like to be able to catch an exception and print a stack trace, showing the call stack with source file and line number (using embedded debugging information I would guess.) Obviously, I want the call stack to be evaluated as lazily as possible - the actual throwing of the exception should do as little up-front work as possible, with the bulk of the work only being done if the the exception

This is a forward of a question from the SourceForge LLVM forum. If anyone has experience with Cygwin and building the C front-end there, please reply and CC Alex. --- Post by Alex Vinokur below --- =============== Windows 2000 GNU gcc 3.3.3 (cygwin special) =============== ./configure ./make I have got compilation error ------------------------------- make[1]: Entering directory

Hi Bill, >> The unwinder delegates the decision of whether to stop in a call frame to >> that call frame's language-specific personality function. Not all personality >> functions guarantee that they will stop to perform cleanups. I was talking about who decides what to do if there are only cleanups all the way up the stack (in C++ the program is terminated without

On Sep 27, 2011, at 4:58 AM, Duncan Sands wrote: > Hi Bill, > >>>> I'm looking at the docs, and while it refers to a "catch-all" clause, >>> >>> hopefully Bill will get rid of the first reference to "catch-all" since >>> that section is inaccurate. >>> >> I *think* this is now correct. Please check. :) >

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

On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <martin at martin.st> wrote: > Hi, > > > On Sat, 15 Aug 2020, Ivan Serdyuk wrote: > > > Just as Shoaib said, libunwind only is useful in environments > > that use > > the Itanium C++ ABI - there's really no use for it in an MSVC > > context > > (either using MSVC or

Hi Peter, Thanks for your response. > On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468

> 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 Feb 2, 2015, at 6:04 PM, Reid Kleckner <rnk at google.com> wrote: > I actually like the unified intrinsic approach here. The backend already has to know things about the personality function. Until recently we would assume that the personality function wants an Itanium LSDA, for example, and dump that out into a target-specific section. Now on Windows we look at the personality

> 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

Hi Logan, So, I just realised clang 3.8 comes with an unwind.h which doesn't have _URC_OK defined (introduced in r262178, just after 3.8 split). But on that commit, the personality routine depends on it for EHABI calls, which is defined by default on ARM environments. The end result is that I can only use Clang 3.9+ to compile libunwind 3.9+.

Martin, good to hear from you. Thanks for the effort - I will test on 32bit and 64bit Windows 10. I will report ASAP. Ivan On Sun, Aug 16, 2020 at 8:42 PM Martin Storsjö <martin at martin.st> wrote: > On Sat, 15 Aug 2020, Ivan Serdyuk wrote: > > > > > > > On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <martin at martin.st> wrote: > > Hi, > >

Hi Renato, > On 1 December 2010 21:37, Duncan Sands<baldrick at free.fr> wrote: >> <catch info> = [personality<ptr>] [cleanup] [catches<list of catches and filters>] > > That would allow you to choose a different personality routine for > every invoke inside the same function (ie. same EH table), which > doesn't make sense to me... if you inline

Hi Bill, >>> I'm looking at the docs, and while it refers to a "catch-all" clause, >> >> hopefully Bill will get rid of the first reference to "catch-all" since >> that section is inaccurate. >> > I *think* this is now correct. Please check. :) I still have some niggles: The unwinder delegates the decision of whether to stop in a

This may be bogus, but do you have: llvm::JITExceptionHandling = true; for the code that generates the dynamic code? It has been a while, but I don't recall what will happen when dynamic code, generated with jit exception handling turned off, invokes libraries which in turn try to unwind the stack via the libunwind api. However given that you say the code works with 2.8, my concern

On Sep 25, 2011, at 1:02 AM, Duncan Sands wrote: > Hi Talin, > >> I'm looking at the docs, and while it refers to a "catch-all" clause, > > hopefully Bill will get rid of the first reference to "catch-all" since > that section is inaccurate. > I *think* this is now correct. Please check. :) > it doesn't >> describe how to construct

There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468. I’ve managed to track it down to a configuration issue. The thing is that in order for libunwind to be usable on ARM Linux, it should be built with the -funwind-tables flag. This flag is conditionally set here: https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294, if the compiler “supports” it. However, the

Hi Bjarke, > * Provide an efficient runtime implementation that does not > depend on reading the DWARF EH information. why? The DWARF EH info encodes two things: (1) how to restore registers; and (2) matching rules for exception objects, and what to do with them. You will need something along the lines of (1) if you unwind out of the middle of functions. As for (2), if you