similar to: [LLVMdev] Unwind, exception handling, debuggers and profilers

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

On 21 March 2014 18:47, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > * There's the table for ARM target: > > - no attribute => emit unwind table > - with nounwind => emit unwind table with cantunwind > - with uwtable => emit unwind table > - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind > > The cantunwind record will stop the

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

Hi all, I feel that there are two problems with the existing infrastructure: * The nounwind attribute is ambiguous for (1) not throwing exceptions and (2) not performing stack unwinding. I feel that it will be better to separate this in two different attributes * There is some problem when the function has both uwtable and nounwind. Although, I think it fine to keep the current definition of

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>

Hi all I have a question about the '-fno-exceptions' option with clang and 'ExceptionsType' on MCAsmInfo. I am looking for a way to avoid generating stack unwinding codes when compiling with the "armv7-none-linux-gnu" triple using clang. I tried the '-fno-exceptions' option in order to do that, but unwinding function symbols like

On 10 February 2014 03:44, Renato Golin <renato.golin at linaro.org> wrote: > On 10 February 2014 02:59, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> It has to be an attribute because of LTO. You can LTO a file compiled >> with -fasynchronous-unwind-tables and one with >> -fno-asynchronous-unwind-tables. That is why we have the uwtable >>

>> The semantics uwtable is just "make sure it is possible to unwind past >> this function". It doesn't include anything more, >> like the ability to run destructors. It is used for ABIs that require >> it for use in debuggers and profilers. > > Well, that meaning fails when you have both uwtable and nounwind, > which means: "generate a

On 7 February 2014 00:19, Richard Smith <richard at metafoo.co.uk> wrote: > This (-fexceptions and -g imply -funwind-tables) seems like it's probably > the right thing for most targets. With SjLj exceptions, -fexceptions > probably doesn't need -funwind-tables. > Thanks, I think that's the general consensus, yes. Do we have such logic in Clang at the moment? My

I assume this "CantUnwind table" is not the same as Unwind table index '.ARM.exidx' at offset 0x818 contains 4 entries: 0x5d4 <main>: 0x1 [cantunwind] because the latter prevent any unwinding, breaking debuggers/profilers/sanitizers. As I understand, the right way to enable basic unwind through any function (without emitting landing pands etc, unless they are needed for

Hello Everyone, This is my first attempt to getting used with the submission process. Trying to get the "good practice" with the coding standard, tools, mailing lists... and already a few questions: - Is it possible to "link" 2 related entries in Phabricator ? one for LLVM and one for CFE ? what's the best way of posting 2 related or dependent patches ? - I'd

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote: > > if (nounwind) > can't unwind > can't unwind == unwind table + no EH directives + no EH table if (uwtable || (!nounwind && need uwtable to unwind)) > unwind table > "need unwind table to unwind" is probably true in almost all cases. At least in all where

On Thu, Feb 13, 2014 at 5:52 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 February 2014 13:47, Evgeniy Stepanov <eugenis at google.com> wrote: >> Hm, I see that -funwind-tables on arm-linux-androideabi target >> replaces this "cantunwind" with a proper unwind table. >> Hence http://llvm-reviews.chandlerc.com/D2762. > > If Android is

Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly

> From: Renato Golin [mailto:renato.golin at linaro.org] > > We're having some discussions about the behaviour of exception handling and Dwarf > sharing unwind logic, tables, etc. and it seems that the code around it wasn't > designed with any particular goal in mind, but evolved (like the EHABI) and now > we're seeing the results from it. > > The problems below

On Thu, Feb 13, 2014 at 5:39 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 February 2014 11:35, Evgeniy Stepanov <eugenis at google.com> wrote: >> Unwind table index '.ARM.exidx' at offset 0x818 contains 4 entries: >> 0x5d4 <main>: 0x1 [cantunwind] > > This is exactly what I meant. > > >> because the latter prevent any

Logan, How would I dump the object file generated by the JIT compiler pipeline? Could you point me to an example of how something like that is done? I’m used to working with the JIT machinery in memory but not writing object files out to disk. I’m have code to generate object files for AOT compilation - is it done the same way? Best, .Chris. On Apr 12, 2015, at 2:27 PM, Logan Chien

This is the only thing that I’ve found that works in terms of getting the exception to propagate out of the JITted function - change the “call” to an “invoke” and hook in the do-nothing landing-pad. https://gist.github.com/drmeister/7a35046f666826206973 Compare line 646 of the file above to the one that I just posted. > https://gist.github.com/drmeister/b97dec956c6ee9ffeb75 The first one

Hi Joerg, You are right, there are three separate issues here: unwinding, debug info and exception handling. Debug and EH require unwinding, but one doesn't require the other and unwinding is not exclusive to either. On 6 February 2014 14:51, Joerg Sonnenberger <joerg at britannica.bec.de>wrote: > (1) Should enough unwind data be provided for a basic, read-only stack > walk?