[llvm-dev] LLVM EH tables much larger than GCC's

[Ryan Prichard via llvm-dev]

On Wed, Jan 10, 2018 at 5:21 AM, James Y Knight <jyknight at google.com> wrote:

>
> On Fri, Jan 5, 2018 at 9:58 PM, Ryan Prichard via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 2. *Termination landing pads.*
>>
>> Clang sometimes uses a landing pad that calls __clang_call_terminate to
>> terminate the program. GCC instead leaves a gap in the call site table,
>> and the personality routine calls std::terminate. For the 4MB
>> libQt5Core.so sample I'm looking at, I think it'd reduce the size of .text
>> and .ARM.extab by maybe 7000 bytes (about 0.18%). (I see about 500 calls to
>> __clang_call_terminate, and I estimate 14 bytes per call, assuming the call
>> site table is using ULEB128 already.)
>>
>> I tried to implement this in LLVM, but couldn't find a good way to
>> represent the calls that must be omitted from the call site table.
>>
>> Is there a reason LLVM doesn't handle this like GCC?
>>
>> Examples:
>>  - C++03: https://godbolt.org/g/7BYbdG
>>  - C++11: https://godbolt.org/g/bnHLvH
>>
>
> See also my comment and Reid's reply here:
> http://lists.llvm.org/pipermail/llvm-dev/2017-February/109995.html
>

Reid Kleckner wrote:

> ... I would say that we should just
> pattern match away our calls to std::terminate in the backend and emit the
> more compact tables, but that is actually a behavior change. It will cause
> cleanups between the thrown exception and the noexcept function to stop
> running.  ...


It seems that some unwinders still run cleanups when the termination
landing pad is omitted?

e.g. For this sample code, GCC emits an empty call site table for func3:

#include <stdio.h>
struct A { ~A() { fprintf(stderr, "~A\n"); } };
void func1() { throw 0; }
void func2() { A a; func1(); }
void func3() noexcept { func2(); }
int main() { func3(); }

Compiling for either x86 or x86_64 Ubuntu, using g++ with
libstdc++/libsupc++, the program still calls ~A. On the other hand, ~A
isn't called if I build with g++ and libc++/libc++abi.

I think I'm not motivated enough to work on changing this LLVM behavior.
The ULEB128 encoding change is more interesting to me. Right now, I think
the biggest problem with that change is the existence of assemblers that
can't cope with the GCC-style EH table assembly. This includes the current
/usr/bin/as on macOS, which suffers from the LLVM runs-forever bug.

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180110/7fb93616/attachment.html>