[llvm-dev] libunwind is not configured with -funwind-tables when building it for ARM Linux?

[Sergej Jaskiewicz via llvm-dev]

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 <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 <https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294>, if the compiler “supports” it.
>> 
> 
> Are you sure that libunwind being built without -funwind-tables is the
> cause of the bug?

Yep, pretty sure, I’ve found that the cause of the problem is the _Unwind_Backtrace function not executing the provided callback. It isn’t doing so because, since libunwind is compiled without 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 armv7l release of clang 8.0 which I happened to have
> installed on an Armv8l machine and the program worked. I was able to
> reproduce the problem with the PR with the default Ubuntu16.04 clang
> (3.8) and libc++-dev package.
> 
> I also note that when looking at the link line for the example in the
> PR, clang was linking libgcc_s and not libunwind so I think the
> problem may be somewhere else. There have been quite a lot of fixes
> since clang 3.8 and its libc++ so it may be worth trying a more recent
> clang.

I’m using mainline just-built clang to build libunwind. Actually, I’m cross-compiling on Windows for Linux.
Also, I’m using compiler-rt instead of libgcc.
And yes, the problem is not with libgcc_s, because, as I’ve said, force-setting the -funwind-tables flag in libunwind configuration makes the problem go away.

So, the main question remains: when we’re configuring libunwind build, CMake checks the -funwind-tables flag and that check fails because the __aeabi_unwind_cpp_pr0 symbol is absent. This symbol should be defined in libunwind, which is not build yet. I’m having a hard time understanding how can this be even possible. Can it be that you are not experiencing the problem because your clang uses libgcc and not compiler-rt?

> 
> Can I ask that you try and narrow down what the problem is, what your
> environment is, and comment on the PR if it helps reproduce? It is
> definitely worth looking at the output of clang -v to see which
> unwinder it is using, by default it will be libgcc_s on Linux.
> 
> Peter
> 
>> However, the CMake check fails with the following error:
>> 
>> ```
>> ld.lld: error: undefined symbol: __aeabi_unwind_cpp_pr0
>> 
>>>>> referenced by src.cxx
>> 
>>>>>              CMakeFiles/cmTC_e9739.dir/src.cxx.o:(.ARM.exidx.text.main+0x0)
>> 
>> clang++: error: linker command failed with exit code 1 (use -v to see invocation)
>> 
>> ninja: build stopped: subcommand failed.
>> 
>> Source file was:
>> int main() { return 0; }
>> ```
>> 
>> No wonder! __aeabi_unwind_cpp_pr0 is defined in libunwind itself, which we haven’t built yet.
>> 
>> If I instead set the -funwind-tables flag unconditionally using `add_compile_flags(-funwind-tables)` instead of `add_cxx_compile_flags_if_supported(-funwind-tables)`, everything is fine and the aforementioned bug is gone.
>> 
>> I’ve found a PR which seemed to address this: https://reviews.llvm.org/D31858 (cc’ing @phosek, @compnerd and @beanz as participants of this PR). It mentions that the __aeabi_unwind_cpp_pr0 symbol is provided by the compiler runtime. However, as I’ve already said, it lives in libunwind, so the problem doesn’t seem to be solved.
>> 
>> I’m very tempted to just set the -funwind-tables flag unconditionally, but I’m afraid it’ll break something. What would be the right solution for building libunwind with this flag for ARM Linux?
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191118/d39ae63d/attachment.html>