This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Add options -(no_)keep_dwarf_unwind
Needs RevisionPublic

Authored by gkm on Jun 10 2021, 6:18 PM.

Details

Reviewers
int3
Group Reviewers
Restricted Project
Summary

DWARF unwind info was superseded by compact unwind as-of macOS 10.9 and iOS 7.0
(circa 2013). Most often, DWARF unwind info is entirely redundant and can be
discarded. In rare instances, complex unwind info cannot be represented by a
compact-unwind entry, and we fall-back to the DWARF frame info.

The intelligent approach is to filter-out all redundant entries in the
__TEXT,__eh_frame section, leaving only those that are necessary fallbacks
when compact unwind is insufficient. However, that's not easy, so unless and
until (maybe later today!) we have a use case that requires the intelligent
approach, we offer the choice of all or nothing.

Diff Detail

Event Timeline

gkm created this revision.Jun 10 2021, 6:18 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: dang. · View Herald Transcript
gkm requested review of this revision.Jun 10 2021, 6:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 10 2021, 6:18 PM
thakis added a subscriber: thakis.Jun 11 2021, 7:44 AM

The intelligent approach isn't _that_ hard, is it? It's < 200 lines in ld64 I think. ld64-linked Chromium Framework leaves some __eh_frame around, so I think removing the whole section generally probably doesn't work.

gkm edited the summary of this revision. (Show Details)Jun 11 2021, 10:14 AM
gkm added a comment.Jun 11 2021, 10:18 AM

The intelligent approach isn't _that_ hard, is it? It's < 200 lines in ld64 I think. ld64-linked Chromium Framework leaves some __eh_frame around, so I think removing the whole section generally probably doesn't work.

Yes, I will do it, but wanted this out quickly. (I changed the description to read "... unless and until (maybe later today!) we have a use case ..." :)

When I looked at the CU entries for Chromium Framework, I saw none that had type bits [24..27] == 4, which means UNWIND_X86_64_MODE_DWARF. What am I not seeing?

int3 added a comment.Jun 11 2021, 10:21 AM

Yes, I will do it, but wanted this out quickly.

No great rush to commit this though :)

The intelligent approach isn't _that_ hard, is it? It's < 200 lines in ld64 I think. ld64-linked Chromium Framework leaves some __eh_frame around, so I think removing the whole section generally probably doesn't work.

Yes, I will do it, but wanted this out quickly. (I changed the description to read "... unless and until (maybe later today!) we have a use case ..." :)

When I looked at the CU entries for Chromium Framework, I saw none that had type bits [24..27] == 4, which means UNWIND_X86_64_MODE_DWARF. What am I not seeing?

I didn't look in detail, I just noticed that ld64 keeps some of the section. So I thought the bits that remain are probably needed? Not sure though.

int3 requested changes to this revision.Jul 17 2021, 1:50 PM

clearing my queue

This revision now requires changes to proceed.Jul 17 2021, 1:50 PM