NativeAOT produces very large `__LINKEDIT` segment on macOS #86707

nxtn-staged · 2023-05-24T13:43:12Z

Description

NativeAOT on macOS typically produces binaries about twice the size with large, almost zero-filled __LINKEDIT segments. Is this expected？

Reproduction Steps

dotnet new console --aot --output Test.Console
cat > ./Test.Console/Program.cs << EOF
using var client = new HttpClient();
Console.WriteLine(await client.GetStringAsync("https://example.com"));
EOF
dotnet publish ./Test.Console/Test.Console.csproj
ls -lh ./artifacts/publish/Test.Console/release

Expected behavior

win-x64

5.0M Test.Console.exe
 22M Test.Console.pdb

linux-x64

6.6M Test.Console
 19M Test.Console.dbg

Actual behavior

osx-x64

 11M Test.Console
 24M Test.Console.dwarf

% bloaty ./artifacts/publish/Test.Console/release/Test.Console
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  37.9%  4.11Mi  34.1%  4.11Mi    [__LINKEDIT]
  26.4%  2.87Mi  23.8%  2.87Mi    __TEXT,__managedcode
  13.3%  1.45Mi  12.0%  1.45Mi    __TEXT,__const
   0.0%       0   9.2%  1.11Mi    __DATA,hydrated
   8.5%   938Ki   7.6%   938Ki    __TEXT,__eh_frame
   5.1%   563Ki   4.6%   563Ki    __TEXT,__text
   4.1%   459Ki   3.7%   459Ki    __DATA,.dotnet_eh_table
   2.7%   297Ki   2.4%   297Ki    __TEXT,__unwind_info
   0.8%  88.5Ki   0.7%  88.5Ki    __DATA,__data
   0.0%       0   0.5%  61.2Ki    __DATA,__bss
   0.4%  39.5Ki   0.3%  39.5Ki    __TEXT,__cstring
   0.3%  30.1Ki   0.2%  30.1Ki    Function Start Addresses
   0.0%       0   0.2%  29.4Ki    __DATA,__common
   0.1%  11.9Ki   0.1%  14.0Ki    [__DATA]
   0.1%  10.3Ki   0.1%  10.7Ki    [14 Others]
   0.1%  10.3Ki   0.1%  10.3Ki    __TEXT,__unbox
   0.1%  9.00Ki   0.1%  9.00Ki    [__DATA_CONST]
   0.1%  6.76Ki   0.1%  6.76Ki    String Table
   0.1%  6.62Ki   0.1%  6.62Ki    Symbol Table
   0.0%  3.39Ki   0.0%  3.39Ki    __DATA_CONST,__got
   0.0%  3.38Ki   0.0%  3.27Ki    [Mach-O Headers]
 100.0%  10.8Mi 100.0%  12.0Mi    TOTAL

osx-arm64

 11M Test.Console
 24M Test.Console.dwarf

% bloaty ./artifacts/publish/Test.Console/release/Test.Console
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  36.5%  4.06Mi  33.0%  4.07Mi    [__LINKEDIT]
  28.6%  3.19Mi  25.8%  3.19Mi    __TEXT,__managedcode
  12.8%  1.42Mi  11.5%  1.42Mi    __TEXT,__const
   0.0%       0   9.0%  1.11Mi    __DATA,hydrated
   8.3%   941Ki   7.4%   941Ki    __TEXT,__eh_frame
   4.6%   520Ki   4.1%   520Ki    __TEXT,__text
   4.0%   451Ki   3.6%   451Ki    __DATA,.dotnet_eh_table
   2.6%   293Ki   2.3%   293Ki    __TEXT,__unwind_info
   0.8%  88.5Ki   0.7%  88.5Ki    Code Signature
   0.8%  88.5Ki   0.7%  88.5Ki    __DATA,__data
   0.0%       0   0.5%  61.1Ki    __DATA,__bss
   0.3%  39.7Ki   0.3%  39.7Ki    __TEXT,__cstring
   0.3%  31.5Ki   0.2%  31.5Ki    Function Start Addresses
   0.0%       0   0.2%  29.2Ki    __DATA,__common
   0.2%  19.0Ki   0.2%  19.1Ki    [14 Others]
   0.1%  9.29Ki   0.1%  9.39Ki    [__TEXT]
   0.1%  8.19Ki   0.1%  8.19Ki    [__DATA_CONST]
   0.0%  4.08Ki   0.1%  7.05Ki    [__DATA]
   0.1%  6.88Ki   0.1%  6.88Ki    __TEXT,__unbox
   0.1%  6.71Ki   0.1%  6.71Ki    String Table
   0.1%  6.58Ki   0.1%  6.58Ki    Symbol Table
 100.0%  11.1Mi 100.0%  12.3Mi    TOTAL

Regression?

No response

Known Workarounds

No response

Configuration

win-x64

> dotnet --info
.NET SDK:
 Version:   8.0.100-preview.4.23260.5
 Commit:    2268e7b15c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win10-x64

linux-x64

$ dotnet --info
.NET SDK:
 Version:   8.0.100-preview.4.23260.5
 Commit:    2268e7b15c

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64

osx-x64

% dotnet --info
.NET SDK:
 Version:   8.0.100-preview.4.23260.5
 Commit:    2268e7b15c

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-x64

osx-arm64

% dotnet --info
.NET SDK:
 Version:   8.0.100-preview.4.23260.5
 Commit:    2268e7b15c

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-arm64

Other information

No response

The text was updated successfully, but these errors were encountered:

ghost · 2023-05-24T13:57:33Z

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

NativeAOT on macOS typically produces binaries about twice the size with large, almost zero-filled __LINKEDIT segments. Is this expected？

Reproduction Steps

dotnet new console --aot --output Test.Console
cat > ./Test.Console/Program.cs << EOF
using var client = new HttpClient();
Console.WriteLine(await client.GetStringAsync("https://example.com"));
EOF
dotnet publish ./Test.Console/Test.Console.csproj
ls -lh ./artifacts/publish/Test.Console/release

Expected behavior

Windows

5.0M Test.Console.exe
 22M Test.Console.pdb

Linux

6.6M Test.Console
 19M Test.Console.dbg

Actual behavior

macOS x64

 11M Test.Console
 24M Test.Console.dwarf

% bloaty ./artifacts/publish/Test.Console/release/Test.Console
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  37.9%  4.11Mi  34.1%  4.11Mi    [__LINKEDIT]
  26.4%  2.87Mi  23.8%  2.87Mi    __TEXT,__managedcode
  13.3%  1.45Mi  12.0%  1.45Mi    __TEXT,__const
   0.0%       0   9.2%  1.11Mi    __DATA,hydrated
   8.5%   938Ki   7.6%   938Ki    __TEXT,__eh_frame
   5.1%   563Ki   4.6%   563Ki    __TEXT,__text
   4.1%   459Ki   3.7%   459Ki    __DATA,.dotnet_eh_table
   2.7%   297Ki   2.4%   297Ki    __TEXT,__unwind_info
   0.8%  88.5Ki   0.7%  88.5Ki    __DATA,__data
   0.0%       0   0.5%  61.2Ki    __DATA,__bss
   0.4%  39.5Ki   0.3%  39.5Ki    __TEXT,__cstring
   0.3%  30.1Ki   0.2%  30.1Ki    Function Start Addresses
   0.0%       0   0.2%  29.4Ki    __DATA,__common
   0.1%  11.9Ki   0.1%  14.0Ki    [__DATA]
   0.1%  10.3Ki   0.1%  10.7Ki    [14 Others]
   0.1%  10.3Ki   0.1%  10.3Ki    __TEXT,__unbox
   0.1%  9.00Ki   0.1%  9.00Ki    [__DATA_CONST]
   0.1%  6.76Ki   0.1%  6.76Ki    String Table
   0.1%  6.62Ki   0.1%  6.62Ki    Symbol Table
   0.0%  3.39Ki   0.0%  3.39Ki    __DATA_CONST,__got
   0.0%  3.38Ki   0.0%  3.27Ki    [Mach-O Headers]
 100.0%  10.8Mi 100.0%  12.0Mi    TOTAL

Regression?

No response

Known Workarounds

No response

Configuration

Windows

> dotnet --info
.NET SDK:
 Version:   8.0.100-preview.4.23260.5
 Commit:    2268e7b15c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win10-x64

Linux

$ dotnet --info
.NET SDK:
 Version:   8.0.100-preview.4.23260.5
 Commit:    2268e7b15c

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64

macOS x64

% dotnet --info
.NET SDK:
 Version:   8.0.100-preview.4.23260.5
 Commit:    2268e7b15c

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-x64

% xcodebuild -version             
Xcode 14.3
Build version 14E222b

Other information

No response

Author:	nxtn-staged
Assignees:	-
Labels:	`untriaged`, `area-NativeAOT-coreclr`, `needs-area-label`
Milestone:	-

jkotas · 2023-05-24T14:02:46Z

@filipnavara Do you have any insights about where the large __LINKEDIT section is coming from?

filipnavara · 2023-05-24T14:07:59Z

@filipnavara Do you have any insights about where the large __LINKEDIT section is coming from?

Unfortunately not. I'd use XMachOViewer to figure out which link edit block is taking the space. I can look at it in more detail next week after I get back from vacation...

MichalStrehovsky · 2023-05-24T20:14:50Z

@ivanpovazan started looking at it this week - in a MAUI app he sent me this segment was 20 MB and I was puzzled what it was when looking at it with a hex editor. A third of the MAUI executable was zeros.

ivanpovazan · 2023-05-24T20:24:57Z

we've noticed a similar (but much much smaller) behaviour with MAUI iOS template app built with MonoAOT, where the section is around 200kb also zeroed out: https://gist.github.com/ivanpovazan/97ec573836caca3f8347b8eafa2cad14
we are currently looking into this

lambdageek · 2023-05-24T20:28:26Z

I think the massive section of zeros is due to native stripping. At least going by the bloaty output that Ivan hsared - "Export Info" is meant to be a trie of information about exported symbols.

Turns out Apple’s strip tool will just zero out the export info trie when removing symbols, but it will not resize the file.

https://opensource.apple.com/source/cctools/cctools-973.0.1/misc/strip.c.auto.html

Note the call to prune_trie does not do anything with the trie_new_size variable after the function returns. prune_trie just removes all the unneeded trie entries and fills the remained of the original block of memory with zeros. (prune_trie source: https://opensource.apple.com/source/ld64/ld64-96.5/src/other/PruneTrie.cpp)

I took a brief look at llvm-objcopy, and I think its Mach-O support will actually redo the layout for the output file, so it might be able to completely remove that section, not just fill it with zeros.

https://github.com/dotnet/llvm-project/blob/2cd4a04a80c6dd0637219751e8d615a854eb76aa/llvm/tools/llvm-objcopy/MachO/MachOLayoutBuilder.cpp#L249-L251

No idea if other things would go wrong if we switched from strip to llvm-objcopy, though. Presumably there were reasons not to use it on Apple platforms.

But it would be worthwhile to save an unstripped binary and look at what was in that section previously.

MichalStrehovsky · 2023-05-24T20:31:47Z

Stripping can be disabled with <StripSymbols>false<StripSymbols>, deleting obj/bin and rebuilding. Various comments in ld64 seems to indicate that this is indeed where symbol table was: https://github.com/apple-oss-distributions/ld64/blob/59a99ab60399c5e6c49e6945a9e1049c42b71135/src/ld/parsers/macho_dylib_file.cpp#L371-L372

MichalStrehovsky · 2023-05-24T20:34:40Z

We're likely not invoking the strip tool correctly. I cannot imagine symbol stripping would work like this by design on Apple platforms that really care about size. Is there a way to see how stripping happens on a normal obj-c/swift/c++ Xcode project?

filipnavara · 2023-05-24T20:48:42Z

There's also the reserved room for code signature at the end of the file/__LINKEDIT section. It should not be this big though.

filipnavara · 2023-05-24T21:49:11Z

We're likely not invoking the strip tool correctly.

I think the strip tool is rarely used on Apple platforms. You just tell the linker/compiler to strip it. One of the reasons is that the linker produces ad-hoc code signatures nowadays, and any further modification has to account for the code signature. It is hard to rewrite the signature, but it's even harder to reallocate the space for the signature (you need to change size of __LINKEDIT section, which has descriptor at the beginning of file, but also calculate the size of the signature at the same time, which needs to know the sizes of all headers and sections).

jkotas · 2023-05-24T22:13:32Z

You just tell the linker/compiler to strip it.

Strip it and save it into a separate file? (ie make it work just like it works with Windows linkers and .pdbs) What is the command line option for that?

ivanpovazan · 2023-05-24T22:15:50Z

After some investigation, there seems to be something wrong with the way we are doing native linking, not stripping.

Regarding the large sections being zeroed out, I am mainly referring to the: __LINKEDIT Export Info section, which seems to include all exported symbols if we do not strip symbols.

To explain it further, if I do the following with what @nxtn-staged provided as a repro:

Add an empty exports.txt file: touch Test.Console/exports.txt
Publish the project via: dotnet publish ./Test.Console/Test.Console.csproj -p:ExportsFile=exports.txt

The size of the app comes down to: 7356576b - 7,3M which ~33% less than 11M originally reported (this was measured on osx-arm64)

The flag above will force passing to the native linker -exported_symbols_list "exports.txt" which seems to affect what ends up in __LINKEDIT Export Info. Stipping the symbols afterwards seems to work just fine.

Additionally, applying the same approach to the MAUI iOS with NativeAOT issue, shaves off the 20MB of zeroes from the binary (similar benefit as described above).

This should be considered when setting up Xamarin integration with NativeAOT and we could probably pass to the native linker something like:

<_MainLinkerFlags Include="-exported_symbols_list &quot;$(_MtouchSymbolsList)&quot;" />

in the Xamarin.Shared.Sdk.targets

filipnavara · 2023-05-24T22:31:14Z

Strip it and save it into a separate file?

For future reference: That doesn't quite apply to Mach-O. In Apple world the debug symbols are not propagated to the final executable. Instead the executable has an assigned GUID and there's a map that points to the original .o files which have DWARF symbols. dsymutil can then be used to collect the the symbols and create a symbol file "bundle" which you can distribute or transfer to another machine (similarly to .pdb files). Lastly, the dSYM bundle can be located anywhere since Spotlight indexes the files and the global search index is also used by lldb.

filipnavara · 2023-05-24T22:39:42Z

@ivanpovazan That kinda rings a bell. We output some obnoxious amount of symbols in the Mach-O .o files in the ILCompiler output because the Apple linker is both buggy and picky. It basically needs to find function boundaries and match them with the DWARF exception info. Unlike ELF there are no explicit function symbols with size. It also notoriously misinterprets symbol+offset relocations in context of the debug symbols, which - once again - means outputting extra symbols (for methods with try/catch and try/finally blocks).

agocke · 2023-05-24T22:43:26Z

Strip it and save it into a separate file?

For future reference: That doesn't quite apply to Mach-O. In Apple world the debug symbols are not propagated to the final executable. Instead the executable has an assigned GUID and there's a map that points to the original .o files which have DWARF symbols. dsymutil can then be used to collect the the symbols and create a symbol file "bundle" which you can distribute or transfer to another machine (similarly to .pdb files). Lastly, the dSYM bundle can be located anywhere since Spotlight indexes the files and the global search index is also used by lldb.

Doing some reading, I don't quite understand what the MacOS standard is, but I agree that it sounds like Mac is different from Linux and it's expected for linkers/Mach-O tools to split debug symbols ahead of time.

Separately, it looks like our default is to produce a "flat" file, which at best seems not-preferred and potentially not-supported, instead of a dSYM bundle, which is the preferred one. I think this is because the runtime build wants to upload a single symbol file, and dSYMs are actually directories. We may need to do some fiddling with the infra to get runtime to produce whatever it needs, but produce dSYMs for customers

ivanpovazan · 2023-05-24T23:07:44Z

Here is another resource explaining the issue and confirms similar approach I gave above with empty exports.txt file: https://github.com/qyang-nj/llios/blob/main/exported_symbol/README.md#strip

I confirmed that doing <LinkerArg Include="-exported_symbols_list /dev/null" /> also works.

@lambdageek

…ies (#18408) # Description This PR reduces the application's SOD (size on disk) by making `__LINKEDIT Export Info` section smaller in the stripped Mach-O binaries. The feature is controlled by `_ExportSymbolsExplicitly` MSBuild property and can be disabled by specifying: `-p:_ExportSymbolsExplicitly=true` Fixes #18332 # Initial problem It has been noticed that during stripping, the strip tool does not resize the export info section after it removes the symbols. Instead it only zeroes out the entries (achieved by calling `prune_trie` function): - https://github.com/apple-oss-distributions/cctools/blob/cctools-986/misc/strip.c - https://github.com/apple-oss-distributions/ld64/blob/ld64-711/src/other/PruneTrie.cpp Thanks @lambdageek for helping to track this down. # Approach As Xamarin build process already collects all the [required symbols][1] needed for the application to run and preserves them during the strip phase, we can use the same file to instruct clang toolchain to export only those symbols via the command line options: `-exported_symbols_list <file>` ([source][2]). This will make the export info section only include what is necessary for the runtime - and at the same time eliminate the problem of the `strip` tool which does not resize stripped symbols. # Investigation setup The issue is observable by building and inspecting the test application: https://github.com/xamarin/xamarin-macios/blob/main/tests/dotnet/MySingleView/MySingleView.csproj and targeting iOS platform in Release mode. ## Results: | Measure | MySingleView - main | MySingleView - this PR | Diff (%) | | :--- | ---: | ---: | ---: | | SOD (bytes) | 13668940 | 13458476 | -1.5% | | .ipa (bytes) | 4829368 | 4827928 | -0.03% | Even though zeroes are compressed well, the SOD is still affected and unused section takes around 1.5% of the most simplistic app size. Much bigger impact has been noted when trying out a MAUI iOS template app with NativeAOT where the `__LINKEDIT Export Info` zeroes take up to 20MB of the SOD, but also with the regular macOS applications: dotnet/runtime#86707 ### Repro current state of MySingleView.app with stripped binary 1. Build the app (you can ignore the need to run the sample, I just did it to make sure the changes do not break anything) ```bash make run-device ``` 2. Print the load commands - [load_cmds_strip.list][3] ```bash otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_strip.list ``` - We are interested in the export info section: ``` cmd LC_DYLD_INFO_ONLY ... export_off 5942960 export_size 207712 ``` 3. Create a hex dump of the export info section - [hex_dump_strip.list][4] ``` bash xxd -s 5942960 -l 207712 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_strip.list ``` - NOTE: Notice around ~200kb of zeroes from ~0x005ab490 to ~0x005dda00 4. Verify exported symbols are correct - [dyld_info_strip.list][5] ``` bash dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_strip.list ``` ### Repro current state of MySingleView.app with unstripped binary 1. Build the app (the make target preserves the symbols) ```bash make run-device-no-strip ``` 2. Print the load commands - [load_cmds_nostrip.list][6] ```bash otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_nostrip.list ``` - We are interested in the export info section: ``` cmd LC_DYLD_INFO_ONLY ... export_off 5942960 export_size 207712 ``` 3. Create a hex dump of the export info section - [hex_dump_nostrip.list][7] ``` bash xxd -s 5942960 -l 207712 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_nostrip.list ``` - Notice that the range: ~ 0x005ab490 to ~ 0x005dda00 now includes exported symbol entries 4. Verify exported symbols are correct - [dyld_info_nostrip.list][8] ``` bash dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_nostrip.list ``` ### Repro the new approach 1. Build the app (the make target uses the new approach) ```bash make run-device-export-syms ``` 2. Print the load commands - [load_cmds_export.list][9] ```bash otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_export.list ``` - We are interested in the export info section ***notice the reduced size of the section***: ``` cmd LC_DYLD_INFO_ONLY ... export_off 5942432 export_size 1048 ``` 3. Create a hex dump of the export info section - [hex_dump_export.list][10] ``` bash xxd -s 5942432 -l 1048 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_export.list ``` 4. Verify exported symbols are correct - [dyld_info_export.list][11] ``` bash dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_export.list ``` --- ## Additional benefits With this approach we could also switch the way strip tool is invoked to always strip all debug and local symbols via `strip -S -x` instead of passing the file with symbols to preserve. This would remove the warning that we are currently getting (which is being ignored): ``` /Applications/Xcode_14.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: warning: removing global symbols from a final linked no longer supported. Use -exported_symbols_list at link time when building... ``` ## Other references: - https://github.com/qyang-nj/llios/blob/main/exported_symbol/README.md [1]: https://github.com/xamarin/xamarin-macios/blob/11e7883da04d80c59e4ffbbc955a3e0e0060ff90/tools/dotnet-linker/Steps/GenerateReferencesStep.cs#L38-L44 [2]: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html [3]: https://gist.github.com/ivanpovazan/d53f8d10be5e4ea9f39a41ea540aa7fa [4]: https://gist.github.com/ivanpovazan/60637422f3ff8cb5f437ddd06a21d9c1 [5]: https://gist.github.com/ivanpovazan/352595ad15c2ac02f38dcb3bd4130642 [6]: https://gist.github.com/ivanpovazan/bf700161f2f3691d1d7381c98d4fa0be [7]: https://gist.github.com/ivanpovazan/44269e4fff5ebd58a4d181451e5c106f [8]: https://gist.github.com/ivanpovazan/38c5afe076502d514a77420af0e10b01 [9]: https://gist.github.com/ivanpovazan/3f663c3c630005f5a578605d48ba807e [10]: https://gist.github.com/ivanpovazan/0bb84f64281d05ab20438aeaed64f13c [11]: https://gist.github.com/ivanpovazan/78b3ba2288f53a2316b9bc46964e7e4f --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>

The extra size appears to be the export list, which is zeroed but not removed when the file is stripped. Exes shouldn't have any exported symbols by default, but ld will include everything by default. We'll fix it up using an ld flag. Fixes #86707

dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label May 24, 2023

ghost added the untriaged New issue has not been triaged by the area owner label May 24, 2023

jkotas added area-NativeAOT-coreclr and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels May 24, 2023

jkotas added the os-mac-os-x macOS aka OSX label May 24, 2023

ivanpovazan mentioned this issue May 24, 2023

Add support for using NativeAOT. xamarin/xamarin-macios#17374

Merged

LakshanF mentioned this issue May 24, 2023

NativeAOT stripped symbol files aren't loaded automatically in MacOS+lldb #86734

Closed

rolfbjarne mentioned this issue May 25, 2023

Investigate/implement __LINKEDIT size reduction xamarin/xamarin-macios#18332

Closed

MichalStrehovsky added this to the 8.0.0 milestone Jun 2, 2023

ghost removed the untriaged New issue has not been triaged by the area owner label Jun 2, 2023

ivanpovazan mentioned this issue Jun 5, 2023

Reduce the size of __LINKEDIT Export Info section in stripped binaries xamarin/xamarin-macios#18408

Merged

agocke added this to AppModel Jun 21, 2023

agocke mentioned this issue Jul 21, 2023

Fix exe size for Mach-O files #89325

Merged

ghost added the in-pr There is an active PR which will close this issue when it is merged label Jul 21, 2023

agocke closed this as completed in #89325 Jul 22, 2023

ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jul 22, 2023

ghost locked as resolved and limited conversation to collaborators Aug 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NativeAOT produces very large `__LINKEDIT` segment on macOS #86707

NativeAOT produces very large `__LINKEDIT` segment on macOS #86707

nxtn-staged commented May 24, 2023 •

edited

Loading

ghost commented May 24, 2023

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

jkotas commented May 24, 2023

filipnavara commented May 24, 2023

MichalStrehovsky commented May 24, 2023

ivanpovazan commented May 24, 2023

lambdageek commented May 24, 2023

MichalStrehovsky commented May 24, 2023

MichalStrehovsky commented May 24, 2023

filipnavara commented May 24, 2023

filipnavara commented May 24, 2023

jkotas commented May 24, 2023

ivanpovazan commented May 24, 2023 •

edited

Loading

filipnavara commented May 24, 2023

filipnavara commented May 24, 2023

agocke commented May 24, 2023 •

edited

Loading

ivanpovazan commented May 24, 2023 •

edited

Loading

NativeAOT produces very large __LINKEDIT segment on macOS #86707

NativeAOT produces very large __LINKEDIT segment on macOS #86707

Comments

nxtn-staged commented May 24, 2023 • edited Loading

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

ghost commented May 24, 2023

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

jkotas commented May 24, 2023

filipnavara commented May 24, 2023

MichalStrehovsky commented May 24, 2023

ivanpovazan commented May 24, 2023

lambdageek commented May 24, 2023

MichalStrehovsky commented May 24, 2023

MichalStrehovsky commented May 24, 2023

filipnavara commented May 24, 2023

filipnavara commented May 24, 2023

jkotas commented May 24, 2023

ivanpovazan commented May 24, 2023 • edited Loading

filipnavara commented May 24, 2023

filipnavara commented May 24, 2023

agocke commented May 24, 2023 • edited Loading

ivanpovazan commented May 24, 2023 • edited Loading

NativeAOT produces very large `__LINKEDIT` segment on macOS #86707

NativeAOT produces very large `__LINKEDIT` segment on macOS #86707

nxtn-staged commented May 24, 2023 •

edited

Loading

ivanpovazan commented May 24, 2023 •

edited

Loading

agocke commented May 24, 2023 •

edited

Loading

ivanpovazan commented May 24, 2023 •

edited

Loading