[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D107049#3100939 <https://reviews.llvm.org/D107049#3100939>, @lhames wrote:

> In D107049#3096727 <https://reviews.llvm.org/D107049#3096727>, @uabelho wrote:
>
>> Hi,
>>
>> We're seeing a problem with this patch in our downstream (not public) buildbots. With an asan-built compiler we see the following:
>>
>>   ...
>>   10:08:55 [ RUN      ] InterpreterTest.CatchException
>>   10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
>>   10:08:55 libc++abi: terminating with uncaught exception of type custom_exception
>>   ...
>
> I suspect that this is a Linux distro that's using libunwind as the unwinder, at least for this test. Linux distros typically use libgcc_s for unwinding. The two libraries have different behavior for their `__register_frame` functions: libunwind's function expects to be passed a single FDE, libgcc_s's expects to be passed an entire .eh_frame section. We try to guess the unwinder in the JIT and use the appropriate argument (see [1][2]), but when we get it wrong this is often the result: we try to pass an .eh-frame section to libunwind's `__register_frame` and it errors out on a CIE at the start of the section.
>
> @uabelho -- In your setup I'm seeing:
>
>   -- Looking for __unw_add_dynamic_fde
>   -- Looking for __unw_add_dynamic_fde - not found
>
> So the question is, how are we failing to find `__unw_add_dynamic_fde` during config, only to crash in it during the test? Is use of libunwind on your platform expected?

Thanks for your reply. Unfortunately I'm not really sure how it's configured or what is expected. I'll try to involve someone who knows.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049