[llvm-bugs] [Bug 50410] New: lld does not clean up __eh_frame section after creating __unwind_info

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50410

            Bug ID: 50410
           Summary: lld does not clean up __eh_frame section after
                    creating __unwind_info
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

Repro:

1. Download
https://drive.google.com/file/d/1j6_f55jX1WYjwrDSmQYbr_X043mLG9L2/view?usp=sharing

2. Unpack, cd chromium_framework

3. Remove `-dead_strip` from response.txt

4. `ld @response.txt` 

5. `otool -l Chromium.app/Contents/Frameworks/Chromium\
Framework.framework/Chromium\ Framework | grep -A10 eh_frame | grep size`
  => size 0x00000000000ad310

6. `ld64.lld @response.txt`, same otool
  => size 0x0000000002859c88

That's 0.676 MiB with ld vs 40.35 MiB with lld. The lld-linked
'Chromium.app/Contents/Frameworks/Chromium
Framework.framework/Versions/Current/Chromium Framework' is 55M larger, so this
is responsible for 72% of the bigger size.


(There's a "prune __eh_frame entries superseded by __unwind_info" TODO in
UnwindInfoSection.cpp for this.)


---

Does anyone know why clang writes __eh_frame in addition to compact unwind?
Having  the compiler write it only to have the linker remove it again seems a
bit roundabout. There's a OmitDwarfIfHaveCompactUnwind in
llvm/lib/MC/MCObjectFileInfo.cpp that seems to control that, but it's set to
true only for watchOS, so it does seem intentional. I don't yet understand why
though. 

(We should fix it in lld anyways, but maybe we could fix it in the compiler as
well -- but I guess there's some reason against the latter that I don't see
yet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210520/0b72d590/attachment.html>