Backport lld fixes from LLVM 15 #13
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Simplifies the code slightly. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D118796
In the case your framework bundles contain relocatable objects, and your objects include LC_LINKER_OPTIONs for the framework, previously they would not be deduplicated like they would have if they were static archives. This was also the case if you passed `-framework` for the framework as well. Reviewed By: #lld-macho, thakis, oontvoo Differential Revision: https://reviews.llvm.org/D114841
…ther than [], which would create a new entry. Differential Revision: https://reviews.llvm.org/D118945
Earlier in LLD's evolution, I tried to create the illusion that subsections were indistinguishable from "top-level" sections. Thus, even though the subsections shared many common field values, I hid those common values away in a private Shared struct (see D105305). More recently, however, @gkm added a public `Section` struct in D113241 that served as an explicit way to store values that are common to an entire set of subsections (aka InputSections). Now that we have another "common value" struct, `Shared` has been rendered redundant. All its fields can be moved into `Section` instead, and the pointer to `Shared` can be replaced with a pointer to `Section`. This `Section` pointer also has the advantage of letting us inspect other subsections easily, simplifying the implementation of {D118798}. P.S. I do think that having both `Section` and `InputSection` makes for a slightly confusing naming scheme. I considered renaming `InputSection` to `Subsection`, but that would break the symmetry with `OutputSection`. It would also make us deviate from LLD-ELF's naming scheme. This change is perf-neutral on my 3.2 GHz 16-Core Intel Xeon W machine: base diff difference (95% CI) sys_time 1.258 ± 0.031 1.248 ± 0.023 [ -1.6% .. +0.1%] user_time 3.659 ± 0.047 3.658 ± 0.041 [ -0.5% .. +0.4%] wall_time 4.640 ± 0.085 4.625 ± 0.063 [ -1.0% .. +0.3%] samples 49 61 There's also no stat sig change in RSS (as measured by `time -l`): base diff difference (95% CI) time 998038627.097 ± 13567305.958 1003327715.556 ± 15210451.236 [ -0.2% .. +1.2%] samples 31 36 Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D118797
Xcode 13 comes with a mismatched platform in libcompiler_rt.dylib, so this creates a linker error on mac catalyst. Fix it by adding it to the skip list. Reviewed By: MaskRay, #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D117925
Adds `-pagezero_size`. `-pagezero_size` commonly used for kernel development.
`-pagezero_size` changes the `__PAGEZERO` size, removing that segment if it is set to zero.
One of the four flags from {D118570}
Now with error messages and tests.
Differential Revision: https://reviews.llvm.org/D118724
This makes it easier to pinpoint the source of the problem. TODO: Have more relocation error messages make use of this functionality. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D118798
This diff has the C-string literals printed into the mapfile in the symbol table like how ld64 does. Here is what ld64's mapfile looks like with C-string literals: ``` # Path: out # Arch: x86_64 # Object files: [ 0] linker synthesized [ 1] foo.o # Sections: # Address Size Segment Section 0x100003F7D 0x0000001D __TEXT __text 0x100003F9A 0x0000001E __TEXT __cstring 0x100003FB8 0x00000048 __TEXT __unwind_info # Symbols: # Address Size File Name 0x100003F7D 0x0000001D [ 1] _main 0x100003F9A 0x0000000E [ 1] literal string: Hello world!\n 0x100003FA8 0x00000010 [ 1] literal string: Hello, it's me\n 0x100003FB8 0x00000048 [ 0] compact unwind info ``` Here is what the new lld's Mach-O mapfile looks like: ``` # Path: /Users/rgr/local/llvm-project/build/Debug/tools/lld/test/MachO/Output/map-file.s.tmp/c-string-liter al-out # Arch: x86_64 # Object files: [ 0] linker synthesized [ 1] /Users/rgr/local/llvm-project/build/Debug/tools/lld/test/MachO/Output/map-file.s.tmp/c-string-literal .o # Sections: # Address Size Segment Section 0x1000002E0 0x0000001D __TEXT __text 0x1000002FD 0x0000001D __TEXT __cstring # Symbols: # Address File Name 0x1000002E0 [ 1] _main 0x1000002FD [ 1] literal string: Hello world!\n 0x10000030B [ 1] literal string: Hello, it's me\n ``` Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D118077
By unsetting this property, we are now able to internalize more symbols during LTO. I compared the output of `-save-temps` for both LLD and ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is concerned. (Thanks @smeenai for working on an initial version of this diff!) Fixes llvm#50574. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D119372
`parseSections()` is a getting a bit large unwieldy, let's factor out logic where we can. Other minor changes in this diff: * `"__cg_profile"` is now a global constexpr * We now use `checkError()` instead of `fatal()`-ing without handling the Error * Check for `callGraphProfileSort` before checking the section name, since the boolean comparison is likely cheaper Reviewed By: #lld-macho, lgrey, oontvoo Differential Revision: https://reviews.llvm.org/D119892
Main motivation: including `llvm/CodeGen/CommandFlags.h` in `CommonLinkerContext.h` means that the declaration of `llvm::Reloc` is visible in any file that includes `CommonLinkerContext.h`. Since our cpp files have both `using namespace llvm` and `using namespace lld::macho`, this results in conflicts with `lld::macho::Reloc`. I suppose we could put `llvm::Reloc` into a nested namespace, but in general, I think we should avoid transitively including too many header files in a very widely used header like `CommonLinkerContext.h`. RegisterCodeGenFlags' ctor initializes a bunch of function-`static` structures and does nothing else, so it should be fine to "initialize" it as a temporary stack variable rather than as a file static. Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D119913
If both an order file and a call graph profile are present, the edges of the
call graph which use symbols present in the order file are not used. All of
the symbols in the order file will appear at the beginning of the section just
as they do currently. In other words, the highest priority derived from the
call graph will be below the lowest priority derived from the order file.
Practically, this change renames CallGraphSort.{h,cpp} to SectionPriorities.{h,cpp},
and most order file and call graph profile related code is moved into the new
file to reduce duplication.
Differential Revision: https://reviews.llvm.org/D117354
Symbols for which `canBeOmittedFromSymbolTable()` is true should be treated as private externs. This diff tries to do that by unsetting the ExportDynamic bit. It seems to mostly work with the FullLTO backend, but with the ThinLTO backend, the `local_unnamed_addr` symbols still fail to be properly hidden. Nonetheless, this is a step in the right direction. I've documented all the remaining differences between our behavior and LD64's in the lto-internalized-unnamed-addr.ll test. See also https://discourse.llvm.org/t/mach-o-lto-handling-of-linkonce-odr-unnamed-addr/60015 Reviewed By: #lld-macho, thevinster Differential Revision: https://reviews.llvm.org/D119767
This mirrors the code organization in `lld/ELF`. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120378
This mirrors the code structure in `lld/ELF`. It also paves the way for an upcoming diff where I templatize things. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120376
This was based off @Thakis' draft in {D103517}. I employed templates to ensure the support for `-why_live` wouldn't slow down the regular non-why-live code path. No stat sig perf difference on my 3.2 GHz 16-Core Intel Xeon W: base diff difference (95% CI) sys_time 1.195 ± 0.015 1.199 ± 0.022 [ -0.4% .. +1.0%] user_time 3.716 ± 0.022 3.701 ± 0.025 [ -0.7% .. -0.1%] wall_time 4.606 ± 0.034 4.597 ± 0.046 [ -0.6% .. +0.2%] samples 44 37 Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120377
…sage This makes it easier to debug those errors. See e.g. llvm#52767 (comment) We take the approach of 'reverse-engineering' the InputSection from the output buffer offset. This provides for a cleaner Target API, and is similar to LLD-ELF's implementation of getErrorPlace(). Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D118903
This gets us closer to the [LLD-as-a-library goal][1]. [1]: https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D121050
This is debug code that is disabled by default. It'll provide a easy way to figure out the impact (if any) of tweaking ICF's hashing algorithm (since a poor quality hash will result in many more `equals*` calls). Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D121051
I found the shadowing a bit confusing
The existing hashing of stubsHelperIndex has mostly been a no-op* for some time now (ever since we made ICF run before dylib symbols get their stubs indices assigned). I guess we could consider hashing the name + filename of the DylibSymbol instead, but I'm not sure the overhead's worth it... moreover, LLD/ELF only hashes their Defined symbols as well. *: Technically it does change the hash value since stubsHelperIndex is initialized to `UINT32_MAX` by default. But since all stubsHelperIndex values are the same at when ICF runs, they don't add any useful information to the hash.
... from a `uint64_t` to a `uint32_t`. (LLD-ELF uses a `uint32_t` too.)
About a 1.7% reduction in peak RSS when linking chromium_framework on my
3.2 GHz 16-Core Intel Xeon W Mac Pro, and no stat sig change in wall
time.
</Users/jezng/test2.sh ["before"]> </Users/jezng/test2.sh ["after"]> difference (95% CI)
RSS 1003036672.000 ± 9891065.259 985539505.231 ± 10272748.749 [ -2.3% .. -1.2%]
samples 27 26
base diff difference (95% CI)
sys_time 1.277 ± 0.023 1.277 ± 0.024 [ -0.9% .. +0.9%]
user_time 6.682 ± 0.046 6.598 ± 0.043 [ -1.6% .. -0.9%]
wall_time 5.904 ± 0.062 5.895 ± 0.063 [ -0.7% .. +0.4%]
samples 46 28
No appreciable change (~0.01%) in number of `equals` comparisons either:
Before:
ld64.lld: ICF needed 8 iterations
ld64.lld: equalsConstant() called 701643 times
ld64.lld: equalsVariable() called 3438526 times
After:
ld64.lld: ICF needed 8 iterations
ld64.lld: equalsConstant() called 701729 times
ld64.lld: equalsVariable() called 3438526 times
Reviewed By: #lld-macho, MaskRay, thakis
Differential Revision: https://reviews.llvm.org/D121052
This reverts commit 112135e. Breaks lld/test/MachO/{icf.s,cfstring-dedup.s,invalid/cfstring.s}
`__cfstring` has embedded addends that foil ICF's hashing / equality checks. (We can ignore embedded addends when doing ICF because the same information gets recorded in our Reloc structs.) Therefore, in order to properly dedup CFStrings, we create a mutable copy of the CFString and zero out the embedded addends before performing any hashing / equality checks. (We did in fact have a partial implementation of CFString deduplication already. However, it only worked when the cstrings they point to are at identical offsets in their object files.) I anticipate this approach can be extended to other similar statically-allocated struct sections in the future. In addition, we previously treated all references with differing addends as unequal. This is not true when the references are to literals: different addends may point to the same literal in the output binary. In particular, `__cfstring` has such references to `__cstring`. I've adjusted ICF's `equalsConstant` logic accordingly, and I've added a few more tests to make sure the addend-comparison code path is adequately covered. Fixes llvm#51281. Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D120137
ld64 breaks down `__objc_classrefs` on a per-word level and deduplicates them. This greatly reduces the number of bind entries emitted (and therefore the amount of work `dyld` has to do at runtime). For chromium_framework, this change to LLD cuts the number of (non-lazy) binds from 912 to 190, getting us to parity with ld64 in this aspect. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D121053
Previously, we aligned every cstring to 16 bytes as a temporary hack to deal with llvm#50135. However, it was highly wasteful in terms of binary size. To recap, in contrast to ELF, which puts strings that need different alignments into different sections, `clang`'s Mach-O backend puts them all in one section. Strings that need to be aligned have the .p2align directive emitted before them, which simply translates into zero padding in the object file. In other words, we have to infer the alignment of the cstrings from their addresses. We differ slightly from ld64 in how we've chosen to align these cstrings. Both LLD and ld64 preserve the number of trailing zeros in each cstring's address in the input object files. When deduplicating identical cstrings, both linkers pick the cstring whose address has more trailing zeros, and preserve the alignment of that address in the final binary. However, ld64 goes a step further and also preserves the offset of the cstring from the last section-aligned address. I.e. if a cstring is at offset 18 in the input, with a section alignment of 16, then both LLD and ld64 will ensure the final address is 2-byte aligned (since `18 == 16 + 2`). But ld64 will also ensure that the final address is of the form 16 * k + 2 for some k (which implies 2-byte alignment). Note that ld64's heuristic means that a dedup'ed cstring's final address is dependent on the order of the input object files. E.g. if in addition to the cstring at offset 18 above, we have a duplicate one in another file with a `.cstring` section alignment of 2 and an offset of zero, then ld64 will pick the cstring from the object file earlier on the command line (since both have the same number of trailing zeros in their address). So the final cstring may either be at some address `16 * k + 2` or at some address `2 * k`. I've opted not to follow this behavior primarily for implementation simplicity, and secondarily to save a few more bytes. It's not clear to me that preserving the section alignment + offset is ever necessary, and there are many cases that are clearly redundant. In particular, if an x86_64 object file contains some strings that are accessed via SIMD instructions, then the .cstring section in the object file will be 16-byte-aligned (since SIMD requires its operand addresses to be 16-byte aligned). However, there will typically also be other cstrings in the same file that aren't used via SIMD and don't need this alignment. They will be emitted at some arbitrary address `A`, but ld64 will treat them as being 16-byte aligned with an offset of `16 % A`. I have verified that the two repros in llvm#50135 work well with the new alignment behavior. Fixes llvm#54036. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D121342
Previously these would crash because `file` is null in the case there is an invalid tbd file. Differential Revision: https://reviews.llvm.org/D124271
Previously, we stored a pointer from the ObjFile to its compact unwind section in order to avoid iterating over the file's sections a second time. However, given the small number of sections (not subsections) per file, this caching was really quite unnecessary. We will soon do lookups for more sections (such as the `__eh_frame` section), so let's simplify the code first. Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D123434
Previously, when encountering a symbol reloc located in a literal section, we would look up the contents of the literal at the `symbol value + addend` offset within the literal section. However, it seems that this offset is not guaranteed to be valid. Instead, we should use just the symbol value to retrieve the literal's contents, and compare the addend values separately. ld64 seems to do this. Reviewed By: #lld-macho, thevinster Differential Revision: https://reviews.llvm.org/D124223
…bols It seems like we are overly asserting when running `-dead_strip` with exported symbols. ld64 treats exported private extern symbols as a liveness root. Loosen the assert to match ld64's behavior. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D124143
Accidentally committed as part of b440c25.
…ac-only tbd files
Before this,
clang empty.cc -target x86_64-apple-ios13.1-macabi \
-framework CoreServices -fuse-ld=lld
would error out with
ld64.lld: error: path/to/MacOSX.sdk/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/
Versions/A/CarbonCore.tbd(
/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/
Versions/A/CarbonCore) is incompatible with x86_64 (macCatalyst)
Now it works, like with ld64.
Differential Revision: https://reviews.llvm.org/D124336
This reverts D117925 since it's no longer needed after D124336. Differential Revision: https://reviews.llvm.org/D124354
This change implements --icf=safe for MachO based on addrsig section that is implemented in D123751. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D123752
With -platform_version flags for two distinct platforms,
this writes a LC_BUILD_VERSION header for each.
The motivation is that this is needed for self-hosting with lld as linker
after D124059.
To create a zippered output at the clang driver level, pass
-target arm64-apple-macos -darwin-target-variant arm64-apple-ios-macabi
to create a zippered dylib.
(In Xcode's clang, `-darwin-target-variant` is spelled just `-target-variant`.)
(If you pass `-target arm64-apple-ios-macabi -target-variant arm64-apple-macos`
instead, ld64 crashes!)
This results in two -platform_version flags being passed to the linker.
ld64 also verifies that the iOS SDK version is at least 13.1. We don't do that
yet. But ld64 also does that for other platforms and we don't. So we need to
do that at some point, but not in this patch.
Only dylib and bundle outputs can be zippered.
I verified that a Catalyst app linked against a dylib created with
clang -shared foo.cc -o libfoo.dylib \
-target arm64-apple-macos \
-target-variant arm64-apple-ios-macabi \
-Wl,-install_name,@rpath/libfoo.dylib \
-fuse-ld=$PWD/out/gn/bin/ld64.lld
runs successfully. (The app calls a function `f()` in libfoo.dylib
that returns a const char* "foo", and NSLog(@"%s")s it.)
ld64 is a bit more permissive when writing zippered outputs,
see references to "unzippered twins". That's not implemented yet.
(If anybody wants to implement that, D124275 is a good start.)
Differential Revision: https://reviews.llvm.org/D124887
When checking the segment name for Swift symbols, we should be checking that they start with `__swift` instead of checking for equality Fixes the issue llvm#55355 Reviewed By: #lld-macho, keith, thevinster Differential Revision: https://reviews.llvm.org/D125250
…n -demangle is specified. PR/55512 Reviewed By: keith Differential Revision: https://reviews.llvm.org/D125732
The <internal> symbol was tripping an assertion in getVA() because it was not marked as used. Per the comment above that symbols creation, dead stripping has already occurred so marking this symbol as used is accurate. Fixes llvm#55565 Differential revision: https://reviews.llvm.org/D126072
- fixed inconsistent indents and spaces - prevent extraneous formatting changes in other patches Differential Revision: https://reviews.llvm.org/D126262
…ls_no_strip_list, -x PR/55600 Differential Revision: https://reviews.llvm.org/D126046
This reduces the time emitStabs() takes by about 275ms, or 3% of overall linking time for the project I'm on. Although the parent function is run in parallel, it's one of the slowest tasks in that concurrent batch (I have another optimization for another slow task as well). Differential Revision: https://reviews.llvm.org/D126785
- fixed newlines - renamed helper function for clarity - added additional comment Differential Revision: https://reviews.llvm.org/D126792
…angle is specified Differential Revision: https://reviews.llvm.org/D127110
This reduces linking time by ~8% for my project (1.19s -> 0.53s for writeSections()). writeTo is const, which bodes well for it being parallelizable, and I've looked through the different overridden versions and can't see any race conditions. It produces the same byte-for-byte output for my project. Differential Revision: https://reviews.llvm.org/D126800
This flag suppresses warnings produced by the linker. In ld64 this has an interesting interaction with -fatal_warnings, it silences the warnings but the link still fails. Instead of doing that here we still print the warning and eagerly fail the link in case both are passed, this seems more reasonable so users can understand why the link fails. Differential Revision: https://reviews.llvm.org/D127564
Just matter of enabling the config option. (Also changed the platform of the input test file to macOS, since that's the default that we specify in the `%lld` substitution. The conflict was causing errors when linking with LTO.) Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D127600
This reverts commit 942f4e3. The additional change required to avoid the assertion errors seen previously is: --- a/lld/MachO/ICF.cpp +++ b/lld/MachO/ICF.cpp @@ -443,7 +443,9 @@ void macho::foldIdenticalSections() { /*relocVA=*/0); isec->data = copy; } - } else { + } else if (!isEhFrameSection(isec)) { + // EH frames are gathered as hashables from unwindEntry above; give a + // unique ID to everything else. isec->icfEqClass[0] = ++icfUniqueID; } } Differential Revision: https://reviews.llvm.org/D123435
This reverts commit 10641a4. Differential Revision: https://reviews.llvm.org/D124561
The allocated memory itself is mutable, so let's expose that to the caller. LLD has a use case for this. Reviewed By: MaskRay, #lld-macho Differential Revision: https://reviews.llvm.org/D120144
This just removes the code that gates the logic. The main issue here is
perf impact: without {D122258}, LLD takes a significant perf hit because
it now has to do a lot more work in the input parsing phase. But with
that change to eliminate unnecessary EH frames from input object files,
the perf overhead here is minimal. Concretely, here are the numbers for
some builds as measured on my 16-core Mac Pro:
**chromium_framework**
This is without the use of `-femit-dwarf-unwind=no-compact-unwind`:
base diff difference (95% CI)
sys_time 1.826 ± 0.019 1.962 ± 0.034 [ +6.5% .. +8.4%]
user_time 9.306 ± 0.054 9.926 ± 0.082 [ +6.2% .. +7.1%]
wall_time 8.225 ± 0.068 8.947 ± 0.128 [ +8.0% .. +9.6%]
samples 15 22
With that flag enabled, the regression mostly disappears, as hoped:
base diff difference (95% CI)
sys_time 1.839 ± 0.062 1.866 ± 0.068 [ -0.9% .. +3.8%]
user_time 9.452 ± 0.068 9.490 ± 0.067 [ -0.1% .. +0.9%]
wall_time 8.383 ± 0.127 8.452 ± 0.114 [ -0.1% .. +1.8%]
samples 17 21
**Unnamed internal app**
Without `-femit-dwarf-unwind`, this is the perf hit:
base diff difference (95% CI)
sys_time 1.372 ± 0.029 1.317 ± 0.024 [ -4.6% .. -3.5%]
user_time 2.835 ± 0.028 2.980 ± 0.027 [ +4.8% .. +5.4%]
wall_time 3.205 ± 0.079 3.383 ± 0.066 [ +4.9% .. +6.2%]
samples 102 83
With `-femit-dwarf-unwind`, the perf hit almost disappears:
base diff difference (95% CI)
sys_time 1.274 ± 0.026 1.270 ± 0.025 [ -0.9% .. +0.3%]
user_time 2.812 ± 0.023 2.822 ± 0.035 [ +0.1% .. +0.7%]
wall_time 3.166 ± 0.047 3.174 ± 0.059 [ -0.2% .. +0.7%]
samples 95 97
Just for fun, I measured the impact of `-femit-dwarf-unwind` on ld64
(`base` has the extra DWARF unwind info in the input object files,
`diff` doesn't):
base diff difference (95% CI)
sys_time 1.128 ± 0.010 1.124 ± 0.023 [ -1.3% .. +0.6%]
user_time 7.176 ± 0.030 7.106 ± 0.094 [ -1.5% .. -0.4%]
wall_time 7.874 ± 0.041 7.795 ± 0.121 [ -1.7% .. -0.3%]
samples 16 25
And for LLD:
base diff difference (95% CI)
sys_time 1.315 ± 0.019 1.280 ± 0.019 [ -3.2% .. -2.0%]
user_time 2.980 ± 0.022 2.822 ± 0.016 [ -5.5% .. -5.0%]
wall_time 3.369 ± 0.038 3.175 ± 0.033 [ -6.2% .. -5.3%]
samples 47 47
So parsing the extra EH frames is a lot more expensive for us than for
ld64. But given that we are quite a lot faster than ld64 to begin with,
I guess this isn't entirely unexpected...
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D129540
This section is marked S_ATTR_LIVE_SUPPORT in input files, which meant that on arm64, we were unnecessarily preserving FDEs if we e.g. had multiple weak definitions for a function. Worse, we would actually produce an invalid `__eh_frame` section in that case, because the CIE associated with the unnecessary FDE would still get dead-stripped and we'd end up with a dangling FDE. We set up associations from functions to their FDEs, so dead-stripping will just work naturally, and we can clear S_ATTR_LIVE_SUPPORT from our input `__eh_frame` sections to fix dead-stripping. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D132489 (cherry picked from commit a745e47)
Previously we only supporting using the system pointer size (aka the `absptr` encoding) because `llvm-mc`'s CFI directives always generate EH frames with that encoding. But libffi uses 4-byte-encoded, hand-rolled EH frames, so this patch adds support for it. Fixes llvm#56576. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D130804 (cherry picked from commit 6c9f681)
If there are multiple symbols at the same address, our unwind info implementation assumes that we always register unwind entries to a single canonical symbol. This assumption was violated by the `registerEhFrame` code. Fixes llvm#56570. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D130208
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Necessary to fix JuliaLang/julia#48020