search for: cantunwind

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 unwinder, and cantunwind will conflict > with the stack unwind information according to EHABI. Thus, we should not > emit cant...

...t; 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 CantUnwind table". Why fails? I would read a "generate a CantUnwind table" as a table that a debugger or profiler can use, but lacks information to allow an exception to be handled. >> I am not too sure about nounwind. I think it is more about using >> unwind for control flow in t...

...uwtable to all > functions and "clang -S -fno-asynchronous-unwind-tables" doesn't. This is remarkably similar to the behaviour I want to create. But that can't be encoded in IR right now wrt. nothrow. These are the options: 1. no attr: don't emit tables 2. nounwind: emit CantUnwind 3. uwtable: emit table 4. uwtable + nounwind: emit table This is because uwtable means *also* debug/profiler use, and emitting CantUnwind could stop them from unwinding, since there is no information on how to continue unwinding the stack. The semantics I want is to be able to separate between EH...

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 fun...

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 using EHABI (I think it is), the default now is to > output full tables all the time, everywhere. This will change to be > the same as x86 soon. It does use EHABI, but at r201326...

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 unwinding, breaking >> debuggers/profilers/sanitizers. > > In that case, my argument stands again. > > >> As I understand, the right way to enable basic unwind through any >> fun...

Is it possible to force llvm/clang to not create a .ARM.exidx section for a bare-metal application that does not use exceptions? I've tried -fno-exceptions -fno-unwind-tables, but it still generates the section with all functions marked as 'cantunwind'. As a temporary punt I tried linking (using lld) with /DISCARD/ on the section, but that seemed to crash lld, which is another problem for another day. Any suggestions? RRM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/ll...

...ables/-fno-eh-tables - Only emits EH directives on ARM, full debug on others, nothing on SjLj * nothrow - Leaf functions, throw(), languages without EH, etc. - On its own, do nothing (no tables are emitted anyway) - +uwtable, do nothing (we don't want to break debug) - +ehtable, emit CantUnwind (the whole purpose) * nounwind - No idea why, but assuming there is a reason - On its own, do nothing (no tables are emitted anyway) - +uwtable, emit CantUnwind (given Logan's semantics) - +ehtable, emit CantUnwind (given Logan's semantics) The primary reason for adding the ehtabl...

...n. Thanks again, RRM On Fri, Mar 1, 2019 at 5:13 AM Peter Smith <peter.smith at linaro.org> wrote: > Hello Rob, > > I'm not aware of any way to suppress the generation of the .ARM.exidx > section with clang. There is some rationale behind this decision as > having a 'cantunwind' makes it possible to mix such code with code > that uses exceptions and still allow exceptions to propagate through > the subset of the program that has been compiled with exceptions. A > linker should be able to compress all the sections down to a single > entry perhaps with a ter...

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 >>

...t Renato created already but I can't edit (account requested to llvm-admin at lists.llvm.org without luck). Could someone help ? So now the proposal: The .exidx and .extab unwind sections are needed, when exceptions are enabled, for unwinding if the function can throw and to hold the EXIDX_CANTUNWIND value if the function does not throw. The problem was already discussed in various threads and defects, so I won't repeat the details but basically that confusion is that if the compiler (or the user) determined that the function cannot throw, we have the NOUNWIND attribute which is not or...

On 12 May 2014 20:20, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > There is a known issue in the code generated by LLVM. > As a workaround, I am adding "-funwind-tables" to compile the unit tests. I thought I had fixed all of them. Do you have a bug number? > BTW, the LLVM revision which I am using is r207501. > It seems that the recent master has come

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

...o create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > Hi Evgeniy, > > I have run in to the some unwind handling table issue recently. After some > investigation, I believe that the correct behavior is to generate > [cantunwind] with and without the -funwind-tables. Thus, I am afraid that > -funwind-tables might not be a good solution for your use case. (i.e. your > program might fall in an infinite loop during stack unwinding.) > > I will send the details for discussion ASAP. > > Sincerely, > Logan...

Hi, I wanted to know if it was possible to force ARM backend to compile a function in ARM while the rest is in Thumb mode. I tried the attributes which is used in GCC but it doesn't work. Here is what I tried: https://pastebin.com/jCr5LPUY Thanks in advance, Uvekilledkenny -------------- next part -------------- An HTML attachment was scrubbed... URL:

...t the flag, the information about the stack frame is lost, so, when _Unwind_Backtrace looks for it, it can’t find it (since we’ve entered the _Unwind_Backtrace stack frame, which lives in libunwind, where no unwind info is present). I’ve looked at the generated assembly of libunwind and found the .cantunwind directives all over the place. > I would only expect that to be a problem if an > exception were being propagated through a libunwind function, and that > shouldn't happen unless something has gone badly wrong. Can you explain what you mean? > I tried the > example with the ar...

...formation about the stack frame is lost, so, when _Unwind_Backtrace looks for it, it can’t find it (since we’ve entered the _Unwind_Backtrace stack frame, which lives in libunwind, where no unwind info is present). >> >> I’ve looked at the generated assembly of libunwind and found the .cantunwind directives all over the place. >> >> I would only expect that to be a problem if an >> exception were being propagated through a libunwind function, and that >> shouldn't happen unless something has gone badly wrong. >> >> >> Can you explain what you...

...abi_attribute 14, 0 @ Tag_ABI_PCS_R9_use .file "noreturn.c" .globl foo .align 2 .type foo,%function foo: @ @foo .fnstart @ BB#0: @ %entry push {r11, lr} mov r11, sp bl bar .Lfunc_end0: .size foo, .Lfunc_end0-foo .cantunwind .fnend .ident "clang version 3.8.0 (git at git-lialp.intra.cea.fr:IL222352/wuc-clang.git d8f7ebf3bc146bce1b1b5e567484a56b60f2ec44) (git at git-lialp.intra.cea.fr:IL222352/wuc-llvm.git d2234a333ed3f101488a33ed3f58e2769cb8fda6)" .section ".note.GNU-stack","",%progbi...

...at language is being used to produce similar results. I believe that emitting the tables on anything that could potentially interact with exceptional code makes sense, but that's clearly a front-end decision. To LLVM, nounwind and uwtables should be absolute: IF (uwtables) IF (nownwind) CantUnwind ELSE Unwind Table ELSE do nothing ENDIF 2. .fnstart/.fnend+friends Another problem is that the emission of unwinding tables (based on .fnstart/.fnend symbols and others) is conditional *only* to the existence (or not) of an exception handling class being loaded (EHABI, Dwarf). Which mean...

...formation about the stack frame is lost, so, when _Unwind_Backtrace looks for it, it can’t find it (since we’ve entered the _Unwind_Backtrace stack frame, which lives in libunwind, where no unwind info is present). >> >> I’ve looked at the generated assembly of libunwind and found the .cantunwind directives all over the place. >> >> I would only expect that to be a problem if an >> exception were being propagated through a libunwind function, and that >> shouldn't happen unless something has gone badly wrong. >> >> >> Can you explain what you...