[cfe-users] objc object file generated for gnustep runtime for ELF target is too big
Perevalov Alexey via cfe-users
cfe-users at lists.llvm.org
Mon Sep 26 08:28:49 PDT 2016
I checked with lto, unfortunately, it didn't get rid of multiple .objc_protocol inclusions.
От: llvm-dev <llvm-dev-bounces at lists.llvm.org> от имени Perevalov Alexey via llvm-dev <llvm-dev at lists.llvm.org>
Отправлено: 26 сентября 2016 г. 16:33
Кому: cfe-users at lists.llvm.org; llvm-dev at lists.llvm.org
Тема: [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big
I'm using gnustep runtime -fobjc-runtime=gnustep with gnustep-libobjc2 (https://github.com/gnustep/libobjc2) and
GitHub - gnustep/libobjc2<https://github.com/gnustep/libobjc2>
README.md GNUstep Objective-C Runtime. The GNUstep Objective-C runtime is designed as a drop-in replacement for the GCC runtime. It supports both a legacy and a ...
For following source file
NSString *str = [NSString stringWithCString:"TEST"];
NSLog(@"test object %@", str);
Compilation in xcode's clang
xcrun -sdk iphoneos clang -arch armv7s -mios-version-min=6.1 -c test_foundation.m -o test_foundation_apple.o
gives following result:
1. object file has only 3156 bytes size
2. and in disassembler only main function
3. the final executable will be 49992 bytes size in this case
But compilation in llvm's clang downloaded from http://llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
clang version 3.8.0 (tags/RELEASE_380/final)
Thread model: posix
gives another results:
1. object file has 159044 bytes size
2. in disassembler a lot of unnecessary .objc_property_list, .objc_method_list, .objc_protocol_list and .objc_protocol in .bss and .data section
3. the final binary size is 101837 bytes size
If comment in above sample #import <UIKit/UIKit.h, the size of object file and binary file in xcode compilation will be the same,
but size binary and object file in case of clang+llvm-3.8.0-x86_64-apple-darwin compilation will be reduced sufficiently:
binary 28569 and object 36952 accordingly.
Looks like all protocols from UIKit.h is placed into binary/object even it's not used there.
I got 3.9.0 from public git (branch release_39 of clang git repository) and found that all protocols interpret as definition (isThisDeclarationADefinition),
and in CGObjCGNU.cpp it's placed into object file whenever it's used or not. With the same open source compiler and -fobjc-runtime=ios protocols are not putting into
object file even in compilation for ELF (I used -target arm-linux-gnueabi).
I used default binutil linker, not llvm's ld.ldd, due to I have problem with relocation on ARM.
I didn't use LTO, due to my linker doesn't have plugin support (I didnt' yet recompile it).
Could somebody point me where to solve that problem, is it AST generation stage, or linkage stage or maybe it's not a problem and just LTO could be solution here?
p.s. It's not only one issue found by me in gnustep runtime generation, and I'll report these issues in next emails.
LLVM Developers mailing list
llvm-dev at lists.llvm.org
llvm-dev Info Page<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
To see the collection of prior postings to the list, visit the llvm-dev Archives. Using llvm-dev: To post a message to all the list members, send ...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-users