search for: local_symbol

Hi, ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: die 141: base type without name). Is it intended behavior? Simple testcase: int main(void) { int i[2]; return 0; } dwarfdump output: clang version 3.0 (tags/RELEASE_30/final): [...] LOCAL_SYMBOLS: [...] <3>< 120> DW_TAG_variable DW_AT_name i DW_AT_decl_file 1 /home/yuri/test.c DW_AT_decl_line 4 DW_AT_type <144> DW_AT_location...

Hi, ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: die 141: base type without name). Is it intended behavior? Simple testcase: int main(void) { int i[2]; return 0; } dwarfdump output: clang version 3.0 (tags/RELEASE_30/final): [...] LOCAL_SYMBOLS: [...] <3>< 120> DW_TAG_variable DW_AT_name i DW_AT_decl_file 1 /home/yuri/test.c DW_AT_decl_line 4 DW_AT_type <144> DW_AT_location...

...itcode. It should not be shipped together with the binary output, just like dSYM bundle. The reason it needs to be done after linking is a limitation of the symbol hiding technique. It requires that the symbols must be resolved. Think about the following case: a.o: T export_symbol T global_symbol t local_symbol b.o: U global_symbol To make sure the bitcode after symbol hiding pass can still link and produce the same output, the pass need to rename them: a.o: T export_symbol --> export_symbol (preserve) T global_symbol --> hidden_symbol_1 (rename, but need to have the same name as the one in b...

Hi everyone I am still in the process of upstreaming some improvements to the embed bitcode option. If you want more background, you can read the previous RFC (http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html <http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html>). This is part II of the discussion. Current Status: A basic version of -fembed-bitcode option