[llvm-dev] Exception handling support for a target

陳韋任 via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 16 05:41:28 PST 2018


2018-01-16 21:03 GMT+08:00 Tim Northover <t.p.northover at gmail.com>:

> On 16 January 2018 at 12:23, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote:
> > Do we have to emit directives in the epilogue, too? One of my test case
> fail
> > due to the directives in the epilogue have been executed. After removing
> >  them from epilogue, the exception is caught as expected.
>
> Emitting directives in the epilogue is hard because the directives
> apply to all instructions after in program-counter order. So if you
> have an epilogue in the middle of a function and emit CFI directives
> saying the registers are back where they were then the unwinder will
> think that applies to the rest of the function too.
>
> To fix that you'd have to emit yet more directives in the basic block
> immeditately following the epilogue. Most people don't bother with
> either because you'd only really need it if you expected to have to
> catch an exception in the epilogue (which is impossible on most
> platforms).


​My test case is:

void foo() {
  throw 0;
}

void bar() {
  try {
    foo();
  } catch (...) {
    throw 0;
  }
}

int main() {
  try {
    bar();
  } catch (...) {
    return 0;      // fail to catch exception thrown by bar
  }

  return 0;
}


, and the assembly of bar looks like


bar:

    .cfi_def_cfa_offset 16
    epilogue​

​    _Unwind_Resume​



The lookup phase of exception handling ​is fine. However, something goes
wrong in cleanup phase. The reason is the unwinder evaluates CFI directives
until _Unwind_Resume, and `.cfi_def_cfa_offset 16` is the culprit. I think
this is what you were saying "have an epilogue in the middle of a function",
right?


-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180116/2ed0f8f9/attachment.html>


More information about the llvm-dev mailing list